I have multiple apps running on the web server. I want to send a special url to an app to begin the login process for a user. This should enable me to jump from one app to the other and have it automatically login without forcing the user to manually login to each app. Has anyone done this? Ive been looking at the example app for handle url and I can see kinda how to do it. However, it’s in the app handle url event and I’m not sure if I want to run a login process there to log the user into a session. Any help would be appreciated. Thanks in advance.
When your session opens and the login page loads, your code checks the URL parameters. If they contain the magic token you need to auto login, you can do that and jump right to the next screen.
We frequently check for a cookie to do the auto login, but this could also be a parameter in the URL.
2 Likes
How would I save to a cookie in the one app and then read the cookie in the next app? I haven’t used cookies much I guess. I was told about handle url but I didn’t hear about using cookies to accomplish this. Thanks for your help.
The cookie would be used for the second login, if the user goes back to the app.
If the user is logged in on App1, this is the scheme I imagine:
-
App1 sends data about the user to App2 using URLConnection. (Server side)
The data would be JSON encoded and contain information about the user and a secure token: abcdefgh for example. For security purposes, better generate a 32 char uuid. -
App2 receives data in
app.HandleURL. (Server side)
App2 then knows that user X will soon access the app using that secure token. -
App1 then sends the user to App2 (client side) using its public URL and a url parameter such as
https://myapp2.com/?securetoken=abcdefgh
In theSession.Openingevent check the url parameters to compare the secure token to what is expected.
App2 knows the secure token is for user X.
To make it more secure, add a timeout for using that specific token (30 seconds seems fair).
App2 also saves a cookie so that the user can automatically log in again when going back to the app.
There are certainly other ways of doing it.
1 Like
Cookies might be a good ‘invisible’ way to handle things. The docs are pretty straight forward, and setting ‘SameSiteStrength’ to ‘None’ might allow you to read/share a cookie as a security token across your multiple sites/apps.
So what actually goes in the App’s HandleURL event to make it login. This is the part I’m missing. The calling with a special url and then using HandleURL to read the special url is all pretty easy. But how do you go from the HandleURL to actually logging into a session? This is the part that I can’t figure out. How do you get the URL parameters from the app HandleURL event into the session open event???
How do you check the URL parameters from the session open event? What is the code?
in Websession:
| URLParameter | name As String | String | |
|---|---|---|---|
| URLParameterCount | Integer | ||
| URLParameterExists | name As String | Boolean | |
| URLParameterName | zeroBasedIndex As Integer | String |
Thank you. I feel like we are inching our way there. lol. I can read the parameter from the session open event. How do I login, or how do I avoid going to the default web page and instead go to the page I want to load after logging in? By default it goes to the default page.
Instead of the URL parameters, you could (and probably should) set your login credentials in the header fields. Both, for sending username + password, as well as the returned response (like a login token)
This way, the data would be encrypted, if you’re using an SSL connection.
URL paramaters are part of the URL address, which is not encrypted.
In case you send the data as JSON in the body, that would be encrypted as well.
See the docs on how to use the Header Fields
That’s not going to work for sending the user to a different web app. The authentication ID for the user accessing the second web app needs to be stored as a cookie (less preferable - EU cookie law) or as a URL parameter. With the limitations of Xojo Web, this is how the authentication ID (which should be a nonce) can be sent with the user’s browser to the second web app.
By the way, the URL address is encrypted with https, the only part of a request that isn’t is the hostname.
1 Like
You’re Right Tim,
But then, cookies are encrypted, since they are stored within a cookie header.
I always thought that the entire URL was just sent unencrypted over the internet 
I had to look it up, since I vaguely remebered that it is not recommended to send sensitive data in the URL parameters.
I found THIS on StackOverflow
It says this:
The querystring is also encrypted with SSL. Nevertheless, as this article shows, it isn’t a good idea to put sensitive information in the URL
URLs are stored in web server logs - typically the whole URL of each request is stored in a server log. This means that any sensitive data in the URL (e.g. a password) is being saved in clear text on the server
I provided a link to a .gov source 
Yes, full paths are stored in the log, but that is why the authentication ID should be a nonce, a one-time-use identifier. It would be meaningless after it’s been used or has expired per @Jeremie_L 's advice.
I would not send the base authentication such as username or password, but a nonce is standard procedure for auto-login things (think email verification links that also log you in).
1 Like
That’s why I try to send all data via the content or headers, and avoid using URLparameters.
Only when I need to point to a certain resource, like a record or something like that.
I only use the one-time-use identifier in case I need to deal with activation codes.
I use access tokens or access keys with an expiration datetime. Either through cookies or via headers.
The expiration is handled in a tokenTable in my database.
Question, is it common to let this token expire, or reset the expiration datetime whenever the user sends a request to the server?
I understand that there might be security breach when such a token is compromised. I always store something like a hashed machineID, with the token.
With a regular web-app I simply use parts of the User-Agent. But when I create an iOS client, that connects with the server, I use the device’s DeviceID.
I don’t think you understand what the use case is here and are trying too hard to shim it into the way you use your API. This discussion is really diverging from what OP is trying to do, so I will refrain from continuing. Consider starting your own thread if you have questions.
Well, the discussion evolved into the way the server and client communicate, and it’s possible vulnerabilities.
But I understand that generating and handling token data would deserve another thread, you’re right about that.