2021r1.1 Ubuntu 20.04
Our app sometimes does things in HandleURL and sometimes as a full web app, depending on the request. When a request becomes a full web app, we would like to pass some info we created in HandleURL to the subsequent session. I thought of doing this by adding a header but strangely, a new header can apparently be added (which doesn’t seem to show up in the session) but a header value can’t be set in HandleURL. Code like Request.Header("MyNewHeader") = "MyNewValue" reports no assignment is possible upon compile.
I’ve had a similar struggle, where I receive a HandleURL (password reset link that has an embedded code in it for security) and after the response is processed I’d like to spawn a session and “delete” the URL to prevent a second submission.
If you stuff a value into a backend database and have the user login go your app, then that value can be quietly retrieved and put to use. But of course this means the user would have to have an account within your app to log into, and the original URL passed into HandleURL would have had to be unique to them.
Are you constructing the URL for the user initially, and are they following that ‘link’ back into the HandleURL of your app?
Its for a public-facing app that sometimes needs user or developer credentials plus other info to set up in order to drive data into third party public systems. These can be complex to set up so it would be really nice to serve a Web-app when they make an error to walk them through it.
There’s no previous log in so it looks like we have to store the information then do a redirect back to ourselves with our own custom SessionID in the query string. That turns a stateless app into a stateful one, and creates a dependency on an underling storage service plus a data security overhead.
But this is exactly the kind of loose client-side stuff I like to avoid and why we code in Xojo for. Because a client-side solution like this requires holding state between Web app instances for example, since the return request might not go to the same instance it came from.
Seems Webresponse allows you to set the header the way you describe.
Another solution would be to store a token corresponding to the handleURL event, and add a parameter in location with the token.
When the app detects a new session which has the proper token, you know it is the same user who visited handleURL. The token should then be destroyed not to be used a second time.
Sure, that’s the kind of thing I was thinking of but it ii’s still slower and creates unnecessary state management between Xojo instances. That’s burdensome when instances exist on different machines. It makes no sense for a tool that executes most custom-code on the server anyway.
That said, a browser is not going to take the things in a response header and then turn around and send them back with the next request. For that, you’re going to want to use a cookie.
Thanks Greg but I don’t think cookies are always available.
Might make a feature request for being able to adjust Request headers in HandleURL similar to WebSession.PreparingSession. Quick and stateless are the watch words of web services.