Hi guys.

The beta process seems to be going well, Downloaded over 300 times. Very few major issues have been reported... Mostly however, by the members of the dev team. This either means that things are 'pretty darned good, or that people really aren't testing. I hope it's the former.

One of the things I'm REALLY shaky about, and need to confirm working is the new behavior of SSL stuff, and the admin_url config entry that was added for 1.10. We need that to be vetted by a few people so that we can be reasonably sure that it is solid.

So please, keep up the good work, and test. We should be releasing a beta3 within the next week, with our changes to the MicroTiny editor, and fixes to the lazy loading stuff... it would be great if we could throw in any fixes to the ssl and admin_dir stuff into the same (and hopefully last) beta.

Thanks.

_________________
Follow me on twitter
--
if you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
----------------
Don't make me angry..... you won't like me when I'm angry....

Hi,

I decided to help out with some late night testing of a clean install of 1.10beta2 on a shared server with a "shared SSL" certificate. I know this may not be the primary target case of the new SSL support, but I've had requests for SSL admin access on such an environment and figured this would be a good test case for the new feature.

So, I configured the install for SSL access for the backend (admin) and non-SSL access for the frontend (site). To summarize, the results were quite good -- it worked remarkable well! I noticed a few small "issues", but overall I found SSL admin to be quite usable for the limited testing I was able to do. Below are a few details of my test config. I'll be happy to provide more details, upon request.

I added two lines to my default config.php (note that the odd values for admin_url and ssl_url are due to the "shared SSL" certificate installed on the server):

That was it! It pretty much just worked after that. I was able to create new content pages. Modify existing page content. Add news articles. Woohoo!

As for the "issues" noted:

1. After I checked the "Use HTTPS for this page" checkbox for a page and then viewed the page via the frontend, I noticed a number of warnings that appeared at the top of the page:
   Code:
   Warning: in_array() [function.in-array]: Wrong datatype for second argument in /home/example/public_html/110/lib/smarty/internals/core.load
   _plugins.php on line 31
2. Firefox 3.6.20 warns that "Parts of the page you are viewing were not encrypted before being transmitted...". I used output of the "Live HTTP headers" Firefox plugin to generate a lists of the http: (vs https:) requests resulting from two different admin page loads and one frontend SSL page load and have attached them to this post:
   a. Admin: Content->Pages
   b. Admin: Content->Pages->Edit Page: Home
   c. Frontend: Load page with "Use HTTPS for this page" option enabled.

Essentially, some javascript and microtiny related files are being referenced using the $config['root_url'] instead of the $config['admin_url']. Not sure if this is by design or by accident, but thought it worth reporting.

Thanks for the nifty new feature -- it's going to come in very handy!

Hope this helps,
fredp

_________________
Towering genius disdains a beaten path. It seeks regions hitherto unexplored.
--Abraham Lincoln, speech, Jan. 27, 1838

I did some SSL testing also:

config.php




Can not confirm these warnings.



I am using FireFox 6.0.1 my browser is not complaining about files not being encrypted. But by watching the FireBug filetrace I can confirm that theme images are sent as http not https when the page is marked as SSL.



I will do some more SSL testing but this is it for the moment.

URL: http://svn.cmsmadesimple.org/svn/cmsmad ... hes/1.10.x
Revision: 7385

Hi,

Here's a little more detail re: the FF 3.6.20 security warning observed:

The initial "warning" is just a small exclamation-point positioned over the "security icon" at the lower right of the browser. I clicked on that icon to get the full security warning, then put the mouse over the icon to get the title/summary, and then took a screen capture (attached below).

Hope this helps,
fredp

_________________
Towering genius disdains a beaten path. It seeks regions hitherto unexplored.
--Abraham Lincoln, speech, Jan. 27, 1838

The {root_url} tag that is used in the default content, and in the default stylesheets will do just that, return the root url as defined in the config.php

I think what I will need to do is to create an {auto_root_url} type of tag (or just modify the root_url tag) that will use some of the internal data and see if an SSL request was made, and if it was, return the $config['ssl_url'] ... simple enough to do, takes time to test to make sure I haven't screwed something else up.

_________________
Follow me on twitter
--
if you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
----------------
Don't make me angry..... you won't like me when I'm angry....

In the latest SVN I've committed:

a: modified the {root_url} plugin to return the ssl_url from the config.php if the request was made via https... there's a param (yet to be documented) to turn this behavior off.

b: Modified the {cms_stylesheet} plugin to:
i: include the https flag in the signature used in generating the stylesheet filename. This will be useful for two pages using the same template when one page is marked as secure, and another isn't.
ii: Modified the filename generation routine to use md5 just so that nothing could be guessed.

In my initial testing now, including viewing the source of the HTML and the generated css everything that should be prefixed with https:// is on a secure page. And two (combined) css files are generated for the same template based on the secure flag.

_________________
Follow me on twitter
--
if you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
----------------
Don't make me angry..... you won't like me when I'm angry....

Works beautiful, great fix.

- All css images are https:// now when a page is marked as [x] use ssl.

- [[root_url autossl=1]] tested to force the root_url to be http:// when in https:// mode.

Thanks for the quick response! Sounds like a nice fix. I'll do more testing after the next beta release, unless switching to the SVN version is preferred.

_________________
Towering genius disdains a beaten path. It seeks regions hitherto unexplored.
--Abraham Lincoln, speech, Jan. 27, 1838

@calguy1000
Can you clarify something regarding the new {root_url} param?

In arnoud's test, he passes an autossl value of 1 to, apparently, disable the new default behavior of the plugin:This seems backwards to me. Wouldn't a param value of 0 (Boolean "off") be more intuitive; since you're "turning off" the default behavior? Or am I missing something? It is late here.

Thanks.

_________________
Towering genius disdains a beaten path. It seeks regions hitherto unexplored.
--Abraham Lincoln, speech, Jan. 27, 1838

autossl is by default ON ... to turn it OFF you would use autossl=0

_________________
Follow me on twitter
--
if you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
----------------
Don't make me angry..... you won't like me when I'm angry....

Great! Thanks for clarifying your intention.

So, given that, I think you might want to change line 25 of plugins/function.root_url.php from
to


Hope this helps

_________________
Towering genius disdains a beaten path. It seeks regions hitherto unexplored.
--Abraham Lincoln, speech, Jan. 27, 1838