Hi,
You need to retrieve all objects that were written in this period out of the
datastore and re-put them - single-property indexes are only written on
putting the entity. If you can't work out which entities were written in
this period, then you will need to retrieve all entities and re-put
thank you.
On 9月5日, 下午1时02分, Simon Knott wrote:
> Hi,
>
> You need to retrieve all objects that were written in this period out of the
> datastore and re-put them - single-property indexes are only written on
> putting the entity. If you can't work out which entities were written in
> this perio
the password was hashed.
i think to query name and password together may take less db ops if
password is wrong. isn't it?
On 9月5日, 下午1时43分, Nick Johnson wrote:
> Also, you don't need to index the password field - just fetch the user, then
> check the password. I sincerely hope you're not storing
Under the old model it would have been a wash. In fact in the original app
engine it would have been worse since it would have required a composite
index. Under the new model querying on the user and password should be
cheaper, but you really won't notice it unless you're getting a lot of bad
p
hash is enough for me. my site is not an e-bank.
On 9月5日, 下午3时58分, Nick Johnson wrote:
> On Mon, Sep 5, 2011 at 4:42 PM, saintthor wrote:
> > the password was hashed.
>
> > i think to query name and password together may take less db ops if
> > password is wrong. isn't it?
>
> The number of oper
Talking abou this, what do you think of using bcrypt.hashpw(password,
bcrypt.gensalt())? I've read in a few places it was supposed to be a
good solution, but I discovered this morning that the AppEngine
version, having to be pure Python, changes the default log_round for
salt generation from 1024 t
+1 bazillion
On Sep 5, 8:13 pm, Nick Johnson wrote:
> 2011/9/6 saintthor
>
> > hash is enough for me. my site is not an e-bank.
>
> This should not matter. If your password database is compromised, the risk
> is not yours, it's your users'. Many users reuse passwords between sites,
> and if your
Also, you don't need to index the password field - just fetch the user, then
check the password. I sincerely hope you're not storing the password in the
clear, though!
-Nick
On Mon, Sep 5, 2011 at 3:02 PM, Simon Knott wrote:
> Hi,
>
> You need to retrieve all objects that were written in this p
On Mon, Sep 5, 2011 at 4:42 PM, saintthor wrote:
> the password was hashed.
>
> i think to query name and password together may take less db ops if
> password is wrong. isn't it?
>
The number of operations is the same; fewer entities would be returned. In
return, though, you're incurring an extr
2011/9/6 saintthor
> hash is enough for me. my site is not an e-bank.
>
This should not matter. If your password database is compromised, the risk
is not yours, it's your users'. Many users reuse passwords between sites,
and if your site provides an easy avenue to determining what those password
On Tue, Sep 6, 2011 at 11:20 AM, Pol wrote:
> Talking abou this, what do you think of using bcrypt.hashpw(password,
> bcrypt.gensalt())? I've read in a few places it was supposed to be a
> good solution, but I discovered this morning that the AppEngine
> version, having to be pure Python, changes
11 matches
Mail list logo
