Do we have sample on how to implement remember password in xojo 2025?
1 Like
i think its a session cookie with expiring date
https://documentation.xojo.com/topics/application_structure/web/introduction.html#getting-started-application-structure-web-introduction-cookies
1 Like
I assume that the purpose is to keep a user logged in.
This is what I usually do:
-
User provides username and password in a client app (or browser).
-
Server checks if both are correct
-
If correct: Server generates a
Token value(a unique string) and stores it in a database, along with the userID. -
The Token value has an expiration date, after expiration, this token record will be invalid and deleted.
-
Server sends back the
Token valueto the client app (browser or other kind of app). -
The client stores the
Token valueas a cookie, or some other local storage means. -
Whenever the client opens the app or re-visits the page, the cookie for the
Token valueis looked up. -
If a
Token valueis found, it is send to the server -
If no
Token recordis found on the server’s database, the client will be redirected to a login-page. -
If a matching Token record is found on the server, and it is not expired, the server will send an OK message to the client.
-
A Token Date-Stamp will be reset to the current date, with every server call. This will update the expiration date of the Token.
-
Further operations in the app will be approved.
Of course there are many ways to further increase security.
For instance, you could generate two Token Values. One is short lived, usually expires in minutes or hours.
A second Token is longer lived. Like several days, weeks or months. During this time, the first Token can be refreshed. After this time, the user will be forced to log in again.
Also, after refreshing the first Token, you could re-generate the first Token.
In case a Token is compromised, it won’t do too much harm. Especially when the first Token has a short lifespan.
I usually add a machine ID to my token. I mix it up in the final Token Values. But in such a way, that I can check this value. I usually generate this ID once, for any user that logs in with a new device.
In the past I used various methods to deal with Authentication. Some simple, some more secure.
1 Like
That’s a terrible way to do that though. Cookies and Local Storage can be copied between machines and would represent a serious security hole without some other form of authentication because a hacker could steal the credentials and keep the user logged in on their own system indefinitely.
1 Like
depending on the web page.
at least someone need access to your pc.
i think hackers will find any way if they really want get access to something.
ok, how about the username to be retained once user get back to the website?
if the http input field name is username and password the password safe from browser could fill it.
disadvantage from browser password safe is it need a master password and possibly they are saved in cloud account.
i guess what you want is just a login without any input inside a short timeframe of few hours what Edwin mentioned.
for just adding the username from cookie it was mentioned in the link above.
1 Like
The approach is very very nice. Thank you for the nice advise.
assuming I done those token, my problem is how to store this token to user computer for later use?
The way you store the token on the user’s device depends on the type of app the user will use.
Client: Web App
In case you use a WebApp, accessed via the user’s web browser, you store the token as a cookie. How to use cookies, can be found in Xojo’s documentation, as mentioned above.
Client: Mobile or Desktop App
In case you build a dedicated app for a desktop computer or a mobile device, like a tablet or mobile phone, you could store the Token in a local file or a database.
Usually you store the Token and it’s expiration date with it. This way you can check if the Token is expired, before attempting to connect to your server app. If it seems to be expired, you ask the user the username and password, and send that to the server.
If it doesn’t doesn’t seem to be expired, you send the Token value to the server. The server can then send a confirmation if that Token value exists in the server’s database.
Usually the Token Value and it’s expiration info is passed via the Headers.
Server App
The Server App is usually a Xojo Web App. In the App object’s HandleURL event, you can check the path property of the WebRequest to check for the endpoint. Below I have some examples of endpoints I usually use.
I put any data I send to the server as JSON in the body of the request. The server responds with a HTTP status code, to confirm the user’s request. I usually send JSON data with some data where my apps can deal with. Like a confirmation message, new tokens etc.
User registration endpoint
/api/auth/register
JSON fields: Username, Email, Password, MachineID
Server will send an activation code to the provided email address.
User Activation endpoint
/api/auth/activate
JSON fields: username or userID, code
Login endpoint
/api/auth/login
JSON fields: Username, Password, MachineID
Token Validation endpoint
/api/auth/validate
JSON fields: TokenValue, MachineID
Forgot Password endpoint
/api/auth/password
JSON fields: Username or Email or UserID, MachineID
Server will email a random activation code. This can be used to reset the password, elsewhere in the app
1 Like
True…
A way to make it hackers a bit harder to steal the credentials is to encrypt it, before storing.
that is actually what I usually do.
Years ago I simply created an encrypted SQLite database file with the credentials. I stored the binary file data as a token.
But, nowadays I use Xojo’s Encryption class to do the magic.
Also, the Token values I usually store have a short life span. Only the refresh token is stored longer.
And I use some kind of key. Constructed as a salted hash of the UserAgent header, and some other characteristics that can be found in the WebSession object. A hacker needs to have the same UserAgent and characteristics in order to have a usable Token.
In a mobile or Desktop App, I send this info via the Headers. I usually include the System’s MachineID, I extract via a MBS plugin.
My point is that tokens are for APIs, not user access. They should be short-lived (like a matter of hours) and the API should offer ways of renewing the token. But what you described about an auto-renewing token each time the user logs in is just asking for trouble in my opinion.
If you want to store something in a cookie, offer to do the username, but if what you’re looking for is to make it easier for users to log in, they should be using a password manager. Even better, make your web app support PassKeys.
Hackers are very good at this game so you shouldn’t create your security protections in a vacuum. The best thing to do is follow a standard of some sort, whether it be username/password (with some requirements to make them harder to guess and periodic change requirements), one-time passwords from an Authenticator, OAuth or Passkeys. Also, never ever send passwords to users in the clear, either in an unencrypted email or an unsecured message system. If you have no other way, use a service like https://onetimesecret.org/
1 Like
Absolutely, Greg!
Right now I take the easy route, I think…
I added a "Login via Apple" or "Log in via Google", etc buttons. They take care of the username / passwords. My app just gets an email address, once the login process succeeds.
But authentication in the server-side app remains a tricky thing.
After the external login process, my app creates a short-lived access token and a longer-lived refresh token.
I’m thinking of adding something that makes the client app unique. In the form of some kind of Device ID or Device-Secret. That ID must match with the ID that’s stored with the token on the server.
But again, an API call can always be fabricated, to send the deviceIDs along with an access- or refresh token.
Sending those “secrets” should be send in the body payload or as headers, since the body and header data is encrypted, when using SSL, right?
Right. They should never be sent in the clear without the benefit of SSL.
1 Like