Sorry your browser is not supported!

Good evening,
i would be happy, if someone helps. Is there a way to protect an area of an app with a password and restore it by sending an e-mail? Maybe someone could forget the password and wan´t it back.
Thanks for your help.

You would need a PHP web server with MySql support and some basic PHP/SQL knowledge, use the HTTP* functions to send data to the server and use the server to send the mail, you would need to write PHP scripts for registration .....

I was working on a user registration system but it is not finished yet, I'll see if I can get it finished.

I have a working example of a program that allows the user to register and log in. Both the register and log in forms are on the one screen (black screen with white textboxes and buttons). It uses PHP/SQL. It also uses and stores a unique key on the device once logged in that it checks every time you start the app to see whether or not it needs you to log in again (this stops the app form asking the user to log in everytime the app opens). A bit like a session cookie.

I can attach an example later today or tomorrow but I'd have to remove some of the extra bits it does like encrypt the data that gets sent back and forth and remove my own database username and passwords etc.

EDIT: I can't remember if my version has forgotten password. It should be easy enough to build on it though. It also does some basic validation checks in AppGameKit before the data is sent and the same again (plus possibly more) in the PHP page before it's loaded into the database.

Thank you, it sounds interesting.

I've attached a working version for register and login. You will need a server to upload the PHP files or set up a test web server on your computer. And you will need a database and a couple of tables set up. In the attached I'm using two tables: users and tokens.

I should mention that the setting up of textboxes and sprites is using some functions I've created to reduce the amount of code needed for each. I didn't fancy converting it back to normal AppGameKit code before sending it through.

The token part allows the user to login from multiple devices and remain logged into each until they login with another user account or logout. I haven't added logged out in the attached examples but you would just need to delete the Username.txt and Token.txt files and clear the username$ variable so is easy enough to add yourself.

I would consider looking at a way to secure and encrypt the data you send back and forth and encrypt some of what you save in the database. I've removed all of the encryption methods I was applying to the data as I couldn't guarantee it was that great. Security isn't really my thing, but basically I was passing the strings through the Base64 function multiple times, reversing the converted string each time. I also added prefixes to each string before it was first converted. The other thing I did was save the email addresses in the database encrypted using SHA512. The one downside to this is that I think you the developer won't ever know what the email address is and you can't have a service or the app send out email notifications or newsletters etc. This is fine for me. In the attached example the email address is saved in the database as is with no encryption.

If you're interested in the encrypted version to see what I've done then let me know and I'll send it through.

EDIT: Have attached a text file which has the SQL code to set up the two tables that's used in the example project

You hash the mailadress using SHA512 but use total useless encryption on the password? What's the benefit of hashing the mailadress?
NEVER EVER EVER save passwords in your database. NEVER EVER EVER try to think of encryption them.

The only good way to do this is hashing the password (best with adding a salt). It should be absolutely impossible to retrieve the password from the generated hash.

Isn't introducing a DB to the mix just adding senseless dependency? If you got tens of thousands if not millions of users, then sure. Anything less than that, might as well defer the DB implementation altogether, store it in a flat file loaded on backend spin-up and keep in memory as a map/dictionary.

The less moving parts you got, the safer and snappier the backend is

edit: oh and what Carhartguy said. Proper procedure is:


1: On client user make password
2: On client password is hashed
3: Hash is sent over SSL/TSL to backend (together with userID if existing user)
4: Backend receives hash, generates salt (usually based off some pseudo-random generator)
5: Backend generates a new userID (if new user)
6: Client receives and stores userID from backend (if new user)
7: Backend appends salt to hash string
8: Backend hashes resulting string from 7
9: Backend stores new hash and salt with userID
10: On client login, user enters password
11: On client entered password is hashed
12: Hash is sent over SSL/TSL to backend together with userID
13: Backend receives hash, looks up salt stored with userID
14: Backend appends the salt to hash string
15: Backend hashes resulting string from 14
16: Backend compares new hash from 15 to hash stored with userID
17: If they match, a kitten purrs
18: If they do not match, a kitten takes a dump on the bed-linen.

simple, huh?

I never said I didn't hash the password! My encrypted version has pretty much everything encrypted and yes I do SHA512 the password. I'm guessing I accidentally removed the hashing of the password when I was trying to remove bits before sharing it.

I never went much further with the example I was working on.

And the point off hashing the email address is that I don't want to know the email address of my users and I wouldn't want someone that got access to the DB to know the email addresses. Being hashed I could still set it up so that they can reset their password if they type in their email address and the hashed version of that matches the one in the DB. If I didn't want the option for resetting passwords I wouldn't collect it at all.

Thank you for your hard work. I have to learn and do some things and then i will try it.