Search

hi guys,

yesterday i updated a sym 2.3.1. install to 2.3.6 and since then i have noticed strange behavior in the members extension.

when i log in (clean slate, cache clear) with my frontend user (userA, id1) everything seems fine at first. i have the following params consistantly:

<member-id>1</member-id>

but when i log off and login again using another user (userB, id86) i can see the username changing between userA and userB on the frontend from page to page. when i take a look at the params it also changes from:

<member-id>86</member-id>

to:

<member-id>1</member-id>

seemingly at random.

i first noticed this with still having members 1.2 installed and tried updating to 1.3 but the problem still occurs.

would be really great if someone had an idea, i'm trying to get to the bottom of this since yesterday morning :(

thanks!
daniel

also i just noticed that i sometimes am able to navigate pages after i log out until i clear my cache manually at which point i am redirected to the login.

What extensions do you have installed, and what response headers do the HTTP GET requests for the pages come with?

installed extensions: http://pastie.org/private/pqih7mg9ljpyygykkmpnw

all updated to the latest version for 2.3.6 except frontend_localisation which is still 1.7.1 because i dont want to lose the translations menu right now.

  1. initial login with userA gets me this
  2. when i go to the debug page, the param is: <member-id>1</member-id>
  3. logout produces this
  4. when i then login with userB i get this
  5. on the frontend it shows userA logged in and the debug page shows param <member-id>1</member-id> (was visited by userA previously)
  6. when i move to another page i get this
  7. on the frontend it shows userB logged in and the debug page shows param <member-id>86</member-id> (was not visited previously)
  8. logout produces this

i just tried with my pre-updated version and when i revisit a page with userB that was perviously visited by userA i get this. this is how it should be.

You have ETags in the response headers. Maybe as a result you're seeing browser-cached versions of the pages?

I'd try disabling ETags in Apache or turning the browser's cache off completely. (In Firefox this can be done with the Web Developer toolbar.)

hm, yeah, i'd just like to know where it comes from. as i said, nothing changed on the system apart from the symphony install. what part of symphony and/or the extensions could produce something like this?

thx for the tip with the ETags. it seems that the extension apipage added ETag support in this commit. when i comment those lines, it works fine again.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details