Web login issue

Hey all,

I’m having a strange situation with weblogin 1.0 on a MODx 0.9.5 install.

Web users can login to the permission required section of the website. However, the problem comes if they logout and then try to login again. The login page routes correctly in the url but the page contents are for the Unauthorized page. This behavior has shown up in FF, IE7 and Opera.

I checked all the snippet calls and as far as I can tell they are all uncached using [! !].

Does anyone have any thoughts or places I can check for fixes?

Thanks!

I have some further details that may help clarify the issue.

I don’t think the problem comes from the WebLogin snippet, but something in the area of web permissions or web document permissions.

The reason I say this is that after logging in with the WebLogin snippet any page that is NOT of the web-user-required documents has a small snippet at the top of the page that detects if a user is logged in and displays a menu button to go to the web-user-required document landing page. This button shows up properly on all pages when the user is logged in and doesn’t show when the user is logged out. So that leads me to believe that it’s something with the document permissions because the problem only shows up when trying to look at the web-user-required docs.

Hopefully that helps us get to the right solution quicker.

Thanks.

It’s still not clear to me the actual problem here. What behavior have you described here that is unexpected or problematic? I can’t seem to figure it out from the description provided so far.

Sorry for the confusion. I’m trying to get a grasp of the situation myself.

We have a site with a section of the site that requires login permissions. We have a weblogin snippet form that gives access to this part of the site. When a subscriber comes to the site, logs in he can view all the subscriber pages. If the subscriber logs out and then tries to login any page that requires login permission to view routes the visitor to the login error page (set in the manager). So the problem only arises AFTER login, logout and attempted login again.

I’ve also found that this behavior is inconsistent. Sometimes I can re-login and things work as I expect them to. This doesn’t help in troubleshooting.

The problem has been witnessed on Win and Mac platforms in the following browsers - Firefox, IE7, Opera 9.

Trying to access pages that require login directly will definitely display the unauthorized_page from the configuration, and they are forwarded to, not redirected (i.e. the URL stays the same as the requested page), so I still don’t see a problem in your description here. This is actually expected behavior. Does your unauthorized_page have the login snippet on it?

The problem is that after logging out of the protected area and then logging back in the second time sends the person the unauthorized landing page rather than the landing page of the protected area. And no matter how many times they try to log in they are constantly sent to the unauthorized page.

I’m not sure what to tell you, but it sounds like you have some kind of conflict in the behavior of your pages; perhaps other snippets on the landing or unauthorized pages, or a plugin is conflicting with what you are expecting. Best advice I can give is upgrade to 0.9.6.1 and see if that solves the problem for you, as I cannot reproduce the behavior you speak of in the default site content in the current releases. If that doesn’t solve it, then you’re going to need to provide more details about the site (i.e. content of the pages, snippet calls, custom javascript, plugins installed, etc.) for anyone to really be able to help.

Thanks for the reply.

The landing page for successful login has the following snippets. there are no additional plugins beyond the default plugins for the site.







simple PHP that displays some links from the tvs.



looks into a dir and grabs address of any CSS files there.



These last two display different menus whether the status of a user is logged in or out. Those are all the snippets.

Upgrading is not an option at this point as the client may not want to pay for that service yet.

Any thoughts?

-bryan