| Prev | Next |
Main difference between accounts and other DAO objects is that accounts, even if they don't exist, have to have their unique name. So even when saving not-yet-existing account object you first have to create account name for it. You can't save empty account using save() method - you have to use createNamed() method. It will generate account name, save account stub in database and return saved name.
It's done this was not without a reason. It's because you have to reserve account name that you try to work with. For instance if you would start creating account named 'Foo' for User1 and then before you would flush those changes to database User2 would request account with same name, that name would not be marked as used in database so you would think both users have their account created. So to avoid such situations you have to create empty account first.
If you won't specify account name (by calling createNamed() without parameters) account name will be generated randomly. This will be unique string. Account name is always returned after account creation.
Another important thing is password hashing. Many modern OTServs use MD5 (outdated) and SHA1 (newest - recommended) password hashing. It means passwords are not stored in RAW format, but only their hashes are stored in database. Thanks to that, even if hacked would get access to database he/she wouldn't know passwords, only useless strings - hashing functions are not to be missconfused with encryption - hashing functions generates only checksum which can't be used to reconstruct initial content (in theory, there currently exist ways like rainbow tables and MD5 has already been prooved to be easily collision-hackable, thats why we recommend to use SHA1).
How to deal with that in POT? Here is the trick - in fact you don't need to deal with that, but this is not always easy to understand for people. The key to understand mechanism is to find out when hashes are generated - at the begining. It means that for POT it doesn't matter if OTServ uses password hashes and if so, then what kind of hashes. In database they are always stored as strings. And after loading it doesn't matter if you compare password or it's hash. It's because of that string1 = string2 means that md5(string1) = md5(string2) and sha1(string1) = sha1(string2). So all you have to do is just generate the hash from password which user give (if your OTServ uses it). After that you operate on it like with normal password:
| Prev | Up | Next |
| DAO objects | DAO objects | Players |