how to reindex a property that once set to indexed = false?

[saintthor]

model is:

class DjUser( db.Model ):
DjID = db.IntegerProperty( indexed = False )
Name = db.StringProperty()
Email = db.StringProperty( indexed = False )
Password = db.StringProperty()

yesterday, i set the Name and Password indexed=False to reduce the
datastore ops. then i notice the gql for user login

DjUser.gql( "where Name = :1 and Password = :2", name, password )

can not work.

i rollbacked to last version and user logins ok. but i met another
problem. the DjUser which has put() during the wrong code is not
indexed. with the right name and password can not be found in the gql
above.

how can i fix it?

[Simon Knott]

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 them.  

It should be noted that query indexes, which use these single-property indexes in the background, are re-generated on deployment.

Cheers,

Simon

[saintthor]

thank you.

[Nick Johnson]

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

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/VYJDjjca21MJ.

To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

--
Nick Johnson, Developer Programs Engineer, App Engine

[saintthor]

the password was hashed.

i think to query name and password together may take less db ops if
password is wrong. isn't it?

[Kenneth]

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 passwords.

the password was hashed. 

And salted?  :-) 

[Nick Johnson]

On Mon, Sep 5, 2011 at 4:42 PM, saintthor <sain...@gmail.com> 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 extra index entry for every record. You _should_ be salting your passwords (and preferably using RCrypt, SCrypt or PBKDF2), though, in which case you can't do an index lookup for the password anyway.

-Nick Johnson

[saintthor]

hash is enough for me. my site is not an e-bank.

On 9月5日, 下午3时58分, Nick Johnson <nickjohn...@google.com> wrote:

[Nick Johnson]

2011/9/6 saintthor <sain...@gmail.com>

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 passwords are, your users are vulnerable elsewhere, on better secured sites.

There is no good reason not to use a proper salting and password stretching scheme; "my site is not important enough" is not an excuse.

-Nick Johnson

[Pol]

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 to 1, otherwise it takes way too long.

In practice, what does this mean for security?

BTW: Since this is so important, you guys should be a Google approved
password hashing function as part of GAE :)

On Sep 5, 5:13 pm, Nick Johnson <nickjohn...@google.com> wrote:
> 2011/9/6 saintthor <saintt...@gmail.com>

[Nick Johnson]

On Tue, Sep 6, 2011 at 11:20 AM, Pol <in...@pol-online.net> 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 the default log_round for
salt generation from 1024 to 1, otherwise it takes way too long.

In practice, what does this mean for security?

bcrypt and scrypt are both good options. scrypt or PBKDF2 are probably better choices on App Engine since the underlying hash functions are implemented in C.

 

BTW: Since this is so important, you guys should be a Google approved
password hashing function as part of GAE :)

There's a feature request for it in the issue tracker. :)

[Patrick Poon]

+1 bazillion

On Sep 5, 8:13 pm, Nick Johnson <nickjohn...@google.com> wrote:
> 2011/9/6 saintthor <saintt...@gmail.com>
>