@Ricardo_Cruz I’m glad you said something as my suspicion was one of the latest Safari updates caused this and it’s been a royal pain since it happened.
Doing a quick search at Brave provided the following context (AI generated):
Safari Localhost Cookie Issues
Safari has a unique behavior when it comes to setting cookies on localhost. Unlike Chrome and Firefox, Safari imposes stricter policies, restricting the setting of cookies with the Secure attribute in local development environments.
Why is this a problem?
Cookies marked as Secure are essential for web security, as they instruct browsers to only send the cookie over HTTPS, preventing transmission over unencrypted HTTP. However, this security feature introduces complexities in environments not using HTTPS, such as local development setups.
Workaround: Remove the Secure attribute
To address the issue of Safari not setting cookies in a local development environment, a practical solution involves removing the Secure attribute from cookies. This allows cookies to be transmitted over HTTP, facilitating local testing without requiring an HTTPS setup. Note: This approach should only be used in development environments due to the security risks associated with transmitting cookies over unencrypted connections.
Best Practices
Use HTTPS in production environments: Ensure that your production environment uses HTTPS to maintain the security and integrity of cookies.
Configure environment-specific cookie settings: Use environment-specific configuration to omit the Secure attribute from cookies in local development environments and enforce it in production environments.
Test and debug locally: Use a local development setup with HTTPS (e.g., https://localhost) to test and debug your application, ensuring that cookies are set and transmitted securely.
Additional Insights
Safari’s behavior is specific to its implementation and not documented by Apple.
Other browsers, like Chrome and Firefox, exhibit more lenient behavior regarding cookie setting on localhost, allowing developers greater flexibility in testing and debugging.
The strict handling of Secure cookies underscores the increasing emphasis on using HTTPS across the web, even in development environments.
By understanding Safari’s behavior and implementing best practices, you can ensure seamless cookie handling and maintain the security and integrity of your web application.
I had already stubbed out my debug build to set my cookies as Secure = False in the WebCookieManager a while ago but this doesn’t appear to help. Tonight I also tried setting HTTPOnly = True but this also didn’t help.
@Ricardo_Cruz Thoughts on where we can go next? Does HTTPS need to be added to debug builds, as much of a pain as this would be with a self-signed cert? Happy to put in a ticket for a feature request or bug fix here.
I’ve been so very tempted to switch over to Firefox instead for my debug testing but haven’t pulled the trigger yet.
If you really need HTTPS for debugging your app locally, you can use the Command Line Arguments and fill --SecurePort and the --Certificate path. You will have to use a valid certificate (or create a self-signed cert) and tell your computer to trust that certificate. Other than that, you should be able to do all this in the current Xojo release.
I might be missing something, but as far as I’m aware, there is anything I can fix in the framework in that sense. It’s a Safari policy that we cannot satisfy automatically
@Ricardo_Cruz What happens if the app is running over HTTP and tries to set a cookie using the Secure cookie option?
This would seem to be an illogical combination, and I wonder if the framework could do something in this case. Maybe a runtime IllegalOperation exception?
It depends on the URL and Browser. Safari will silently ignore the attempt, while Chrome will allow to do it on local URLs.
I think that can make sense at first, but it will be breaking code that is actually working at the moment (again, depending on the Browser). In this specific case, I’m more in favor to document this behavior, instead of raising a runtime exception.
I just set things up and they work great. The only issue is that Xojo keeps bringing things up at http and on the wrong port so I need to manually modify the URL.
I believe my prior similar feature request would solve this problem as well:
No bug, it always debug as http:// and not https://
You can create a feature request if you want but I guess you should be able to check if the opened URL is http and request https instead.
Something like (not tested) on your WebSession Opening event:
#If DebugBuild Then
If Not Me.Secure Then
Me.GoToURL("https://127.0.0.1:8081")
End If
#EndIf
So the problem isn’t that I don’t know what the port should be or that I can’t setup my app to use the proper protocol or port, but instead the issue is with #5 where Xojo continues to use http as well as port 8080. I have zero problems with going directly to https://127.0.0.1:8081/ in Safari to get to my running debugged app.
So my point here is threefold…
As we can’t define exactly what URL and parameters are launched by Xojo, one can’t override it’s default URL
As Xojo knows that --secureport=8081 is passed in…
A. It should default to HTTPS
B. It should also use 8081 for the service port instead of 8080
It’s a small nit in the overall scheme of things, but likely could be a huge pain in a developer’s side. For me personally, I’ve mitigated this by turning off the Launch Browser switch (woohoo that this recently got added) and have squirreled away the proper URL into my Safari Favorites that I see when I open up a new tab.
I don’t understand why you think this should work like that.
If you deploy a Xojo web app on a server (on the web with its domain) you should be able to connect to it using http or https (if you added the secure configuration) unless you configure it some way to force https and the browser will change to https even if you type http. Using Lifeboat you also have the option to allow http, https, or force https.
Did you try the code that I posted? If you Run your web app it should try to connect to http regular debug port (8080 maybe) and if the connection is not secure then redirect the browser to https on port 8081. Is this not what you want to do? Is not working for you?
Or maybe I don’t understand the problem.
Note: when I wrote (not tested) I mean: I didn’t generate the self signed certificate to make port 8081 secure and make https work on my local machine. I have done that in the past but not today. The redirection to secure URL works but is not connecting because I don’t have the correct configuration at this time.
I think you’re missing that this is purely for debug and to work around the more recent Safari development where cookies are no longer stored/read if you’re running under HTTP. For those of us making apps that include forms with stored cookie values, this ends up being a huge issue as you’re constantly having to refill out form data during development. See the start of this thread to find out more.
Yes your code works find but is sort of a hack/workaround for Xojo potentially not doing the right thing in of itself. It knows that secure has been turned on and what port is being used, so it should be “smart” enough or have the logic to go there versus the current hardcoded/static value that it keeps using.
I think an optional custom debug url solves the problem in a simple and predictable way. It can be useful to test names on a network as well. The secure port thing is ambiguous and has already led to confusion.
It should be a way for us to query the ‘Command Line Arguments’, see that we have (or not) --secureport=XXXX there and use my ‘hack’ (as you call it, that I don’t remotely see it as that) to adjust the code to redirect or not to a secureport and which one.
If there is no way to know when debugging that we have something on ‘Command Line Arguments’ then a Feature Request may be a good idea.
I was just saying (and still am) that the IDE not going automatically to the secure port that you define with a command line argument is a bug. It was designed that way from a time where https was rare. Feel free to create Feature Request to make sure that, as https is common now, Xojo offers easy ways to debug using https, custom local domains, etc.
I was just trying to help use https without you need to turn off the launch browser and type the URL yourself. That’s it and that’s all.
I’m sorry if I came off at all dismissive as that wasn’t my intention. Also my use of the word hack wasn’t to degrade your solution one bit, but more so to call out it was a way around a potential Xojo inadequacy. Your solution is fine and I appreciate your comment as this could potentially help others down the road.
Unfortunately my responses here don’t always include all the details as my posts are often lengthy enough that I try to shorten where I can. My response to Ricardo above could very much have been “This works great. Thanks!” because my internal workflow doesn’t rely upon the Xojo’s launch of the URL at all, whether it’s correct or not.
During my code » run » debug cycle, I find the launching of the URL incredibly frustrating. If I’m working on a web app, after the first launch, there’s no reason for me to get subsequent launches as nearly 100% of the time I already have the URL up and running in Safari. So getting a duplicate tab gets annoying really fast. Add in the fact that the URL provided isn’t the URL I’m generally working on (e.g. there’s a path and parameters to the URL where I normally work), so the OOB settings don’t work for me at all. The Launch Browser switch has been my new best friend to say the least.
So why did I actually provide an expanded response with some questions and commentary? There’s several reasons for this including to try and make Xojo better for all. I noticed something that seems a bit off so rather than ignore it, I’m digging a bit deeper. This response also provides another opportunity in an attempt to persuade Ricardo and/or the Xojo team to take on my outstanding request:
And finally, as these threads often go, I’m hopeful that the information within might help someone today or in the future if/when the stumble across it. @AlbertoD Your code is great for this because even if it doesn’t fit my own purposes precisely, it’s very likely to be a solid solution for someone else.
So yet another lengthy post by me, but I’ll wrap things up with some newer thoughts that I have on all this… If Safari is now mandating HTTPS debug for cookies, it almost seems like Xojo should switch over to HTTPS debugging by default in order to eliminate a ton of folks having similar problems down the road. Or maybe at the very least have a switch to turn on HTTPS debugging and a field/button to tie in your certificate. Of course these two things could just be a wrapper around the command line parameters, and it would be a good way to expose the solution to folks. Otherwise, unless if you find this thread, one could end up down a rabbit trail for a while trying to figure out why their cookies aren’t working.
