As many people are dealing with ssl and ses and building links. How about this approach for 3.0
Including an ssl detection mechanism (mostly an ssl interceptor internally), that can place its value in the request collection. Therefore the request collection can have the following:
event.isSSL()
Then all the methods in the event will switch to use ssl. Also, relocation methods.
The tricky part is when the ssl url is different than the normal url. This is due to shared ssl certificates or the like. So I am now thinking that you can have also the following on the ses interceptor:
setBaseSSLURL() and
setBaseURL()
The baseSSLURL is optional and will be the same as the base URL if not used. Then this can produce another setting also:
That sounds like a pretty decent approach. One question I haven't
entirely though through on that, however, is how would it cover sites
that respond to multiple dns names (say, abc.com and www.abc.com) and
they have a wildcard cert that protects any subdomain in there. Is
that going to screw up the need to set a BaseURL? I guess if you don't
need to redirect then the BaseURL just wouldn't matter and you'd
continue on with whatever domain name the client came in with and not
worry about it, so I don't think its actually a problem. Just
something I like to think about outloud in case it makes people
recognize an actual potential issue.
Yes, ssl support will only exist for ses. As an initiative, we want ses to be the main way to write coldbox applications. However, I know it is a transition. So features like this or for example the new eventless view dispatching (new) will also only rely on ses.
As for multiple domains, you can use the #cgi.http_host# and it can be dynamic for ALL domains.
Could you use the settings in the environments file? That might solve
it somewhat. For the other, wouldn't a multi-url site have some sort
of custom interceptor in place to do site detection, etc.?