Hi Rene,
So you have a range of options here, and it all depends on what you are doing.
a) perhaps your mobile app needs a user id, but not necessarily a password at all. So you could leave the field blank, and not use it. For example I have a "clockings" app - I need to ID the user, but a single "UserID" suffices. The user doesn't need a "password".
b) perhaps the app needs a password, but you will "remember" (aka "store") it on the device for them. (You should assume it's stored unencrypted). If the user loses the device, and the finder is able to run the app, then they will be logged in as the actual user. Terrible for a banking app, but probably just fine for a "driver on the road" type app.
c) perhaps the user needs to enter a password every time the app is used. Think banking app, or something like that. In this case, again, you won't use the Password field at all - you'll use a "memory form field" to capture that.
On the server side you again ave lots of options. Of course yes you should ideally not store the password. You should store a Salted Hash of the password. So in the syncDevices procedure you can take the incoming password value, sync, hash it, then store the result of that.
Lots of options - you just need to figure out which approach you best want to take.
cheers
Bruce
Topic: Password in the Settings Table (Read 3024 times)