Quote:

Please do! It is important that XOOPS fully supports SSL.

The only issue I am aware of is inconsistent handling of the secure flag on cookies. Patches are in for session and remember me cookies. There are others, but they present less of an issue and are not being changed at this time.

If you do find anything else, please let us know. We really need it to work correctly.

Thanks!

Quote:

Thanks for reporting this! This appears to be a safe change even if you are not using https for your main site, since it affects the URL for Google API. I've added this change to version 2.5.9. The replacement, Recaptcha v2 is supported there already, and always uses https.

Quote:

xBootstrap's look comes from override templates in the theme. The theme's templates need to be cloned, too. The publisher clone process does NOT do that.

When you clone publisher, it creates clones of all of its templates under the new name. You would have to manually make a copy of the xbootstrap/modules/publisher folder and templates to match the new cloned name.

For example, if you clone "publisher" to "pubclone" then you need to copy xbootstrap/modules/publisher to xbootstrap/modules/pubclone and then rename all the templates from publisher_*.tpl to pubclone_*.tpl. Also, there are things in most of the templates which will need to be adjusted, too - variables like $publisher_url, included templates like db:publisher_header.tpl, css class names publisher-*, and constants _MB_PUBLISHER_* would all need to be changed too.

The clone function makes a lot of little changes to the files. It would probably be possible to make a "clone publisher templates in a theme" function based on the existing cloning code, but it could get messy.

Crazy idea that should work. You could copy the xbootstrap/modules/publisher templates directly into the publisher/templates directory and then clone it. That way the cloning process would make all the needed changes. The only downside would be that any clones would be locked into xbootstrap -- not really a problem if that is what you are using. Might be worth trying.

Quote:
We have been plotting this out for some time. (That's why I have not done much with theme selector PR. Most of what it touches will not be in the next release.)

On the front facing themes, sucio and zetagenesis will be gone. The default theme will remain, as we do need to maintain legacy theme compatibility in 2.5.9, and the default theme will serve as a reference for testing legacy compatibility.

The plan is to add two new bootstrap based themes. There is still one slot open, so if you know of a general purpose bootstrap theme that will serve as an inspiration for the new XOOPS user, and will be easy to customize, please suggest it!

On the admin side, the changes have already been made based on known usage.

Quote:

OK, I see the issue. Here is the cookie arriving at the browser:


.in.ua is a public suffix. It has the same meaning for setting cookies as a top level domain, i.e. .com, the same as .co.uk

For security, browsers will not accept cookies for domains that consist of only a public suffix. The cookie is being sent, but is rightfully ignored by the browser.

XOOPS 2.5 does not properly handle public suffixes. The code which attempts to determine the domain to use for cookies is obsolete, and produces incorrect results in cases like this.

For this case, I would recommend hacking the "XOOPS_COOKIE_DOMAIN" define,

In include/common.php, line 98 looks like this:

Change that to read:


With that change, the remember me functionality should work.

This issue has been addressed in part in 2.6 with public suffix list awareness. Also, the XOOPS_COOKIE_DOMAIN should be configured at installation, rather than on the fly. I'll look and see what can be done to help in the 2.5 series.

Sorry I didn't pick up on that sooner. Hope this helps.

I'm trying to take a look, but so far the activation stage is stalled. I'll keep watching for it, and see what I can tell.

Quote:

Quote: just a little

Just retested it -- works fine.

"Remember me" depends on a cookie, so anything that will interferes with cookies will cause it to not work.

One common issue is that cookies for an IP address as opposed to a domain name do not work in many browsers due to security concerns. An example is a test site with XOOPS installed onhttp://127.0.0.1/ will not work properly, while installing it onhttp://localhost/ works fine.

Switching back and forth is not considered best practice. It used to be common, but the current wisdom is "If an asset is available using HTTPS, always request it with that."

The XOOPS_URL define is (supposed to be) used to build all URLs. It is possible to hack mainfile.php to dynamically change the define on each invocation, but that is not recommended. There may be issues with that approach, particularly form caching that was not designed from the ground up to be scheme sensitive.

It of course is your call -- this is just my perspective on the issue

Quote:

Make sure the definition of XOOPS_URL in mainfile.php has the https:// protocol.