I have a web application that works fine. Now I would like to deploy it as standalone in https. Can I do that with Xojo 3.1?
You can’t do it with just Xojo. You need to put something in front of it to handle SSL. You can use a variety of open source software for that. Nginx and HAProxy are two that I’ve used. I believe stunnel and stud are also workable but I haven’t tried either of them for Xojo web apps. I did run one of them years ago for something, but I can’t remember what it was now. You can also use Apache with mod_proxy and mod_ssl if you already have it running on your server.
The benefit of something like Nginx or HAProxy is that you can also run multiple instances of your app across more than one machine to handle increased loads. It’s very likely that if you have a well trafficked site you’d need something like this anyway.
It would be nice to have SSL built in for smaller sites though.
[quote=40696:@Kevin Windham]You can’t do it with just Xojo. You need to put something in front of it to handle SSL. You can use a variety of open source software for that. Nginx and HAProxy are two that I’ve used. I believe stunnel and stud are also workable but I haven’t tried either of them for Xojo web apps. I did run one of them years ago for something, but I can’t remember what it was now. You can also use Apache with mod_proxy and mod_ssl if you already have it running on your server.
The benefit of something like Nginx or HAProxy is that you can also run multiple instances of your app across more than one machine to handle increased loads. It’s very likely that if you have a well trafficked site you’d need something like this anyway.
[/quote]
Yes, and it works. However, it is not officially supported by Xojo and there are some small problems. Please, vote:
Thanks for informations. I will try Nginx and HAProxy; I also thinking to deploy my app as CGI and run it in XAMPP enviroment.
[quote=40697:@olivier vidal]Yes, and it works. However, it is not officially supported by Xojo and there are some small problems. Please, vote:
<https://xojo.com/issue/23891>[/quote]
I read the case, and I wonder what the specific scenario would be that you have in mind. I don’t care for the messages browsers report to users when not fully implementing SSL on a site, so I just redirect them to SSL and use it for the whole site if I need it.
In your case maybe you want just the login secure, or just payment secured? In that case, I think you could use ACLs and redirects or header insertion in the proxy to clue the app in to whether or not the connection is secured.
Maybe there’s another scenario you have in mind. The feedback report doesn’t mention any specific protocol support or proxy app that would be handling the two way communication. Is there some sort of standard for this? I think it might be easier to get some support for the request if there were more specifics.
[quote=40765:@Kevin Windham]I read the case, and I wonder what the specific scenario would be that you have in mind. I don’t care for the messages browsers report to users when not fully implementing SSL on a site, so I just redirect them to SSL and use it for the whole site if I need it.
In your case maybe you want just the login secure, or just payment secured? In that case, I think you could use ACLs and redirects or header insertion in the proxy to clue the app in to whether or not the connection is secured.
Maybe there’s another scenario you have in mind. The feedback report doesn’t mention any specific protocol support or proxy app that would be handling the two way communication. Is there some sort of standard for this? I think it might be easier to get some support for the request if there were more specifics.[/quote]
My main problem is the app needs to be accessible to both “public” users and members (logged in). When a member wants to login, I switch to https for the whole site as you state. But the problem is that causes a whole new session to launch, causing delay and needing to keep track of where the user was to return them there after the login. I’d like to be able to tell the front-end proxy (nginx or whatever) to switch that connection to SSL without it affecting the session. This is why I think I’ll need communication both ways between the proxy and the app.
You seem to know more about all of this than me (which is very little). Is something like this even possible? What about these “ACLs and redirects or header insertion” you mention? How does that work? On many of my apps, the option of using SSL only on the login and payment sections would be great. Will this still need a session reload?
I’ll have to think about it a bit. Theoretically you should be able to have a browser switch to https which the proxy would handle and the web app needn’t know about, but with Xojo apps there is that push connection that maintains a link to the browser.
If the browser is on a non secure page, switching to a secure page would require downloading all the page assets securely wouldn’t it? I think that will force the framework to build a new session since a Xojo app doesn’t load a whole new page when something is clicked or submitted.
I don’t think it would be hard to set up something where you can find out if a user’s connection is secure to the proxy, but I don’t think it will be easy or maybe even appropriate to maintain session state across secure and non-secure connections with the way the framework operates.
Maybe a Xojo engineer could comment and see if it’s worth even attempting.
Am I missing something? Why would https prevent users who are not logged in from seeing the site? Why not just use https all the time, and redirect any incoming http requests to https?
Traditionally, HTTPS should only be used for pages that need it, as it prevents full browser caching, increases server load, and increases load time. That would be kind of difficult on WE, though. Also, be sure a reverse proxy is on the same machine as the app, and connected via an interface that does not leave the machine. Otherwise, you’d still have an insecure layer. Or you could use two machines on a private subnet. My point is be aware of how the proxy and the app connect to each other.
Is it still valid?
On the NUG, some members had a different opinion. As Charles Yeomans:
[quote]That browser caching of resources retrieved via https are not cached appears to be a myth.
http://blogs.msdn.com/b/ieinternals/archive/2010/04/21/internet-explorer-may-bypass-cache-for-cross-domain-https-content.aspx
http://blogs.gnome.org/jamesh/2008/05/01/firefox-ssl/
Safari appears to be caching files that can reasonably be cached.
Reverse proxy setups are quite standard, and RSWE should support them. In addition to making it easy to provide secure connections and more easily support scalability, reverse proxy support makes it easy to implement part of a web site using an RSWE app.
To offer one use case, the ability to put RSWE behind a reverse proxy would make it trivial to implement part of a web site using RSWE. In fact this was exactly the situation I was trying to implement.
And I wasn’t sure that this was an unsupported configuration; RS is still advertising support for FastCGI, so I thought perhaps the use or RSWE in a reverse proxy configuration might have been overlooked :)[/quote]
Yeah, I don’t think the caching thing is much of an issue any more. I think it’s more to do with load. However, if your site is so heavily loaded that running SSL becomes an issue, it seems you could probably afford to get a second server and run the SSL Proxy on it.
Running sites on a recent MacMini, the difference between having SSL and not is unnoticeable and the sites load pretty much instantly. Much faster than many pages I typically browse online. That’s one reason I think it makes sense to just run the whole site through SSL. We have a redirect set up in the proxy so any HTTP request never actually makes it to the app. They just get redirected to the HTTPS URL instead.