Thread

I am testing V1.6 with MSM on an installation with two sites. Both sites ran prior to the upgrade as separate domains, with one as the “main” domain and the other as a secondary domain. The System Security and Session Preferences, User Session Type, was set to “Cookies and Session ID” prior to the upgrade and worked reliably. The host is pmachinehosting - CA DC. This problem has to do with Security and Session Preferences, User Session Type.

Both sites consist of both public and private areas, and the private areas of both sites are accessed via a standard login form/template which returns to a “landing” template which checks the group_ids using advanced conditionals, and then embeds templates accordingly. This may be unorthodox but it works on Site1 but not Site2.

Since the upgrade, the domain that formerly was “main” (now “Site1”) still works properly with the same User Session Type setting as before, but the secondary domain ( now “Site2”) accepts the login but then fails on the landing page unless it’s Session Type setting is “Cookies Only.” The nature of the failure is one whereby the just-logged-in user group_id is not recognised by a conditional.

This is no a big deal for now, but security is an issue with this site and I need to know if this is normal behavior or not, because I would prefer to go back to the old setting at some point.

For what it is worth the “landing” page code for both sites is structured identically, and the code which fails is as follows(reduced to essentials and pseudo-coded for clarity):

{if group_id == 1}
   {embed="blog1_templ_group/template_1"}
{if:elseif group_id == "something_else"}
   {embed="blog1_templ_group/{template_2"}
{if:else}
   {embed="{blog1_templ_group}/{reject_access_template}"}
{/if}

Because the group_id is not recognised, the “access failure” template is embedded. I get the same results with simple conditionals, and the also when I replace the embeds with HTML redirects. The problem is firmly due to non-recognition of the group_id after successful login. The code is not between weblog entry tags.

I have checked that the template access settings are such as to permit access (but then, this fails even with the superadmin’s ID)

I re-uploaded all the new code that came with 1.6 and rechecked the settings and permissions. If there is anything wrong there I am too stupid to recognize it - time to call the cavalry.

The build - Build:  20070622
Both Firefox and Safari show same symptoms. The Terminal is OS X

So it definitely works if you’re logged in as group 1?  Like if you log out, clear all cookies, log in as somebody in group 1- you see the first embed.

And if you do the same- log out, manually clear your cookies- log in as superadmin on the front end- you see the default ‘denied’ template- even if the second conditional is set for superadmins id?

When you test to confirm- turn ‘show queries on’- so you can see what’s going on with the attempt to get your group id.  Oh- and maybe print out the group id on the page so you can see what it’s coming up with as well.

Hey Robin - I don’t really follow your review of my post, so I’ll try to simplify.

1. Two sites/blogs, Site 1 and Site 2
2. Site 1 is default, i.e.at EE root level
3. Site 2 is a secondary domain and therefore at EE root plus one level inside it’s own folder with it’s own Path.PHP etc as per standard.
4. Each site/blog has it’s own login/landing/access template
5. The login templates are identical, except they return to their own different landing templates
6. The landing templates are identical as to how they test for group_id, but differ in what they do about it.
7. The code worked prior to upgrade to 1.6 with User Session Type set to “Cookies and Session ID”
8. After upgrade to 1.6, the code still works for login to Site 1 (default) with User Session Type set to “Cookies and Session ID”, but fails for login to Site 2.
9. Site 2 can be made to work with User Session Type set to “Cookies Only”
10. The logins do not fail - ie, login is successful for both sites.
11. The Site 2 code that fails when User Session Type is set to “Cookies and Session ID,” is in the template to which the login form returns, and looks like

{if group_id == 1}
   {embed="blog1_templ_group/template_1"}
{if:elseif group_id == "something_else"}
   {embed="blog1_templ_group/template_2"}
{if:else}
   {embed="blog1_templ_group/reject_access_template"}
{/if}

**Edit - my pseudo code was ugly so I made it prettier**

It does no matter which group_id you test for (and are logged in as) the test simply fails when you are logged in with the correct ID. Note that it is not the login that fails, but the subsequent code that sorts out who is logged in. Whoever is logged in, is not recognized - only on Site 2

I know this is convoluted, but then so is the problem.
Template parsing does not shed any light. Later when the customer stops working I will turn on “show queries” to see what can be seen.

Clearing cookies and caches has no effect, and the problem is identical and different terminal/browser combinations, both Mac and PC/Windows

If you put the global:

{group_id}

On the denied template- what’s it showing as your group id?  For the one that fails?

It shows ID=3 which is “Guests”

even though Post Login message says “You are now logged in.”

Aha- that helps.  Hm.  OK- are you using multi-site login?

Do you mean “Allow multiple log-ins from a single account?”

Yes I need that because of the way my customer works, but disabling it makes no difference.

I’m going to need to poke this one- I just don’t use sessions on the frontend.  But let me do some testing- let you know what I spot soon.

Hmm, with cookies only everything works as expected, but if you try to implement login with Sessions, things fail?  That’s actually a surprisingly good outcome, since we can largely narrow the problems down to sessions.

Could you enable php and add this to your test template that Robin built with you?

<?php
global $SESS;
echo $SESS->userdata['group_id'];
?>
<hr >
{group_id}

The answer is:

3 and 3 (guest)

Hmm, ok, can I ask that you use cookie-only authentication until we have a chance to narrow this down a bit?

Hmm, ok, can I ask that you use cookie-only authentication until we have a chance to narrow this down a bit?

OK - let me know if I can do anything else to help.

Will have this fixed in the next build, being released today.  We put it the site id in one place but not in another for Session IDs to work right.

Great support people - really appreciated.