Joe,
>Sorry, I understand you are trying to get around your self signed cert but that is not going to work.
No, I'm trying (and have succeeded with the above described work-around) to allow users to login to my web site using an unencrypted connection, while still providing encrypted access where I deem it necessary. If you had not supplied the Sign-In module to accomplish this, I was about ready to do it myself. Thanks!
>My advice is buy an SSL certificate, places like rapidssl.com have pretty low prices for budget SSL certificates.
Really, I would have no use for a paid certification, except to make idiotic browsers happy. My users trust my word that my domain is owned by me. They don't require someone else's certification. Fact is, they'd probably laugh to think they should trust veri-sign and IE more than they trust me.
The whole trust supply chain of so called "certificates" is simply subterfuge and a great income generator for those collecting fees. The only reason I can see to "buy" one is to make someone else a little richer and me a little poorer. When I connect to visa.com, I trust my typing more than I trust a CA, whether or not SSL is employed. All a CA says is that https://visa.com is as good as connecting to http://visa.com, an assertion my 5 year old can make with equal authority based on the simple rules of logic.
The annoying part of all this is that browsers present utterly non-sensical or misleading messages to people using them with SSL unless the site has bought into the whole CA scam. I've read the messages: they defy all rules of logic (FF) or are misleading (IE). It is truly bizarre, unless you ascribe collusion to the whole process.
>>As Joe D said there is no way to make it use ssl for some users and not others particularly for sign in since it doesn't know who the user is when they have not yet signed in.
Well, you guys often say "there is no way". I can think of three ways to provide it, and there are other ways to secure login without using SSL.
1. Have a login that takes user name only, looks it up, and if the user is an admin, send him to an SSL page for his password.
2. Use the method I described above. Mojo users construct two separate links essentially.
3. Mojo itself could be modified to allow it.
And finally, there are javascripts available on the net for encrypting post data that can be unencrypted by a web app but not by anyone else. The SSL requirement then disappears. But that would require Mojo mods too.
>>If SSL is available it will be automatically used on important security pages like the login and register and user profile pages.
That is a nice feature for out of the box configuration, and the way it should be, but is patronizing to say it must be so.
>>There are good reasons to redirect out of SSL on pages...
Again, a default configuration might suggest this, but there are perfectly good reasons not to redirect as well. Since you are all business minded: browser warnings about mixed encrypted/unencrypted content would suggest to me, the site owner, that I had not set something up properly. With the redirect, I totally miss that information, unless I closely watch for a little lock icon on the status bar, or the exsistence of a tiny little "s" in the address bar.
Furthermore, redirecting my site's encrypted traffic to unencrypted behind my back, or without my permission, seems like improper etiquette. If Apache or IIS did that, they'd be out of business overnight :)
>>Hope it helps,
Well, Mojo does help, otherwise I would not be using it! Thanks for making it freely available. It is a decent product that I can supply to people without having to fuss with much, despite its odd internal workings.