Is it save to expose entity ids of data that is in Google Datastore. For example in my code i have entity with this id:
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
@Extension(vendorName="datanucleus", key="gae.encoded-pk", value="true")
private String id;
The id is going to be similar to this: agptZeERtzaWYvSQadLEgZDdRsUYRs
Can anyone extract password, application url and any other information from this string? What is the meaning of that string?
You can use the KeyFactory to convert to keytoString, stringToKey as follows URL Google App Engine:
the ID that I believe that it was an unique id for the data storage in Google App Engine.
Key instances can be converted to and from the encoded string representation using the KeyFactory methods keyToString() and stringToKey().
When using encoded key strings, you can provide access to an object's string or numeric ID with an additional fields.
I hope it helps.
Tiger.
That entity ID contains the object id, appliation id, and object class name. It's just an encoded string. Not really any sort of security risk.
If you navigate to localhost:4321/_ah/admin , you can take advantage of the sdk datastore viewer, where you will see that every kind of entity has a KEY field and a NAME/ID field;
Whether you use long, String or Key as your @PrimaryKey, there will be an ID/Name column with a String/number, and a KEY column, with the encoded key for said ID. As mentioned in other posts, this encoding hashes {md5s, most likely} your appspot application id, the fully qualified classname of the data object, and whatever you specify as the @PrimaryKey.
The only time you will ever want direct access to this field is if you absolutely don't care what the data is named,{when you need your program to find it, but humans won't be searching for it by guessing words into a text box}, or when you WANT to have multiple objects of the same type and name {maybe using a version int?} then you should use the encoded key syntax. Both KEY and ID are present in the db whether you put a field in your class, using the encoded key syntax just gives you access to this value.
Also, there is an available speed bonus for applications that use encoded keys... There are only two types of queries: SELECT * and SELECT _ _ key _ _ {spaces used to show there are two _}. For large data sets in AJAX apps, the only efficient way to paginate data is to select all the keys, send them to the client, and have the client ask for 0->X number of records, build links for the other X->Y results, and query the server with the first set of encoded keys for full data, parse response into nice little lists, and avoid loading 397 server data objects that aren't immediately useful.
Sending encoded keys up and down the wire might take a little more bandwidth than unencoded keys {unless you're as long winded at naming things as I am!}; but it shaves those cpu cycles on appengine, makes your quotas happier, and everybody's app runs just a fraction bit faster!
This key, even if somehow unhashed, will only expose data as sensitive as whatever you make a PrimaryKey. You app password is not involved, nor will user passwords in any sane data model. About the only thing that might {BIG might} leak is a user email address, if you use the provided User class for authentication, or the class names you use in your source.
...Basically, only information already available in watching a firebug request or two could possibly be exposed.