Can the location of a SSL Certificate be specified to a Stand Alone Web App so that it may be stored someplace other than the same folder as the executable?
Using symbolic link files on Windows, OS X and Linux it is possible to store those files in the same folders as the executables, store the SSL Certificates elsewhere and have the executables find the SSL Certificates. My preference is to specify to the executables where to look and avoid having to manage symbolic link files on each platform.
Even better would be to have a choice of specifying the location as a property in the IDE, with code in the WebApplication.Open event and as a command line parameter where each specification supersedes the previous.
If there is no way to specify the location and the only workaround is a symbolic link then I will follow up with a feature request in Feedback.
Whats the functional advantage or necessity to opening the server before firing the open event? In a web app you cant have any input from a user in the open event anyway. I cant, off the top of my head, think why you should be required to start the server before firing the open event. If you started the server after the open event we could set the sockets and the max sockets and everything else including the SSL certificate folderitem reference from code and our own configuration rather than from command lines which always interfere and bump into the command lines Im already sending to tell me things.
Of course, you could just provide a pre-open event into the application event of a stand alone web app, but that seems like a larger departure than just opening the server when the open event completes.
I will also sign on to this as its really against the rules to suggest that a user has to show package contents and load the cert file inside an app, plus it would get overwritten everytime they update the app and possibly negate the app signature?
Symbolic Link files can be used to address both concerns but the technique is much less elegant than being able to specify the name and location of the Certificate file in the IDE, in the WebApplication.Open event (or some other event) and on the command line. Having all three options with each one superseding the previous would provide tremendous flexibility.
A similar approach to specifying port numbers and maximum numbers of sockets would be welcome too.
The more I think about this in regards to what Im doing with it the more I think that I dont want you to even start the server after the open event. I want a command to start the server after Ive gotten my setup from wherever. Is there any reason that a stand alone app needs to start its server when it starts up at all?
I know Im doing it a little weird, but all of my layout and configuration for the dynamic pages are loaded after the open event. I actually open a socket to talk to the parent app and get all my setup data from that. Though the server is running it cant actually do anything until Ive received that information, so it would be even better if I had a way to start the server myself given a set of parameters that I specify or set before starting the server.
As I continue to mull this over, what would happen to a hit that was received before my open event completes anyway? I havent got any of the structures setup that the pages need globally in order to load anything anyhow.
Having access to the server available before my open event means I might get a hit that couldnt be handled anyway.
This is not exactly what you’re looking for but along the same lines. The idea is for us to be able to control whether or not the built-in stand-alone web server is active. Having it paused upon startup of the web app would partially achieve your request. Having the built-in stand-alone web server reconfigure itself upon each resume would get even closer. That would mean being able to change the name and location of the certificate, change the port numbers and change the maximum number of sockets with each resume. It’s a lot to ask for but would extend the possibilities for web apps.
Im not entirely sure what the term pause means in relation to a server. You can start and stop listening on the port. And when stopped you should be able to change any of the parameters of the server (ports, maxports, ssl file location, local interface everything) and then restart the server with those new settings.
It just doesnt seem like starting the server BEFORE the open event, or even starting it automatically given command line arguments is necessary. Im sure it was done that way to solve some problem or make something easier in the initial development, but it certainly doesnt have to be that way. Let me start and stop the server and give me access to those parameters when the server is stopped. Of course, I know nothing about the internal implementation of the server, but if its anything like every other server implemented in xojo this really shouldnt be a huge deal once they understand that its important.
It’s open for definition, which appears to be evolving in this conversation and the related Feedback feature requests. I like the greater flexibility that comes with your suggestions. Hopefully they are not too difficult to implement. It would be great to see them scheduled for 2015.
I guess it all hinges on why is it necessary to start the server before running any user code. There may be a perfectly good reason for that. But if not, or if it can be worked around, then once we have code running there is no reason that we cant start and stop the server or set any of those parameters ourselves.
First of all, the order of these events does matter because it has been this way since the Web Framework was first introduced, and changing the order stands to break existing user code that expects that everything is set up before the Open event runs.
Another part of this is that 98% of the framework for standalone and cgi is shared, and some of the requirements we have are related to that, whether we like it or not.
As far as the Pause/Resume possibility goes, about the only thing we could do would be to call StopListening / Listen respectively on the server socket(s). Mind you, that would basically pull the plug on any users that were already connected, and they would get the disconnect message after a bit of time.
I’d like to know more about why it’s so important that you be able to start and stop the servers on your own though. i don’t see anything in this discussion that couldn’t be handled by simply terminating the app and starting it again with new parameters.
For Web Apps running on Windows, when an administrator pauses a Windows Service (aka the Web App) they expect it to actually pause. The same with resume. The best we can do in our Web Apps now is close new Sessions as they’re created by new connections. It would be better if there were no new connections or Sessions at all while paused.
In regard to being able to specify the name and location of the Certificate being used for secure connections, having it outside of the Web App path/bundle/etc. would make upgrades easier and make sharing it amongst multiple Web Apps easier. Haven’t tried the latter yet but can see it being useful to have one Certificate instead of many copies.
Well, like I said above, the behavior would be that all users would be kicked off immediately (unless you set up a loop to wait for everyone to quit, but Windows would probably pull the plug on you anyway).
This part I have no trouble with. I think being able to specify the certificate location is a great idea.
In the WebApplication.Pause event I cleanup and Quit each WebSession. What I can’t do is prevent a new WebSession from being created with each new connection. It would be helpful to have a means of ignoring new connection attempts while the Windows service (aka Web App) has been paused by the administrator.
Regarding Windows, when an administrator pauses a service, it’s up to the developer of the service to pause execution. Windows does not pull the plug in any way. Web Apps can continue to operate normally despite being listed as paused in the Windows service manager. Since it is up to us to pause our Web Apps, we need a means of doing just that.