Opened 3 years ago

Last modified 2 years ago

#11636 new defect

Moodle sends returning users to login page even though they are logged in

Reported by: greenfeld Owned by: martin.langhoff
Priority: normal Milestone: xs-0.7
Component: school server Version: Development build as of this date
Keywords: Cc:
Blocked By: Blocking:
Deployments affected: Action Needed: diagnose
Verified: no

Description

Moodle sends returning users to a login page even though they are logged in.

  1. Register an XO to the schoolserver.
  2. Using Browse, visit the schoolserver's home page.
  3. Exit Browse, maybe reboot the XO for good measure.
  4. Using Browse, return to the schoolserver's home page.

Expected: We see the schoolserver's home page.
Actual: We get redirected to a login screen for the schoolserver which asks for a password, even though we are already logged in.

Seen on XS-0.7 Beta 1 with 11.3.1 os27.

Change History (9)

comment:1 Changed 3 years ago by dsd

Can't reproduce on 11.3.0 for XO-1 nor XO-1.5, Browse-129.1.

comment:2 Changed 3 years ago by greenfeld

Reproduced on a custom country 11.3.0 XO-1.5 derivative with Browse 129.1.

The first time I approached the page I used the "Local schoolserver" link from Browse's Home page (available via the Home button). The second time I got this message I used the same link as well.

It looks like if you save and restore the Browse activity while at the schoolserver's main page that you come back to it without an issue.

comment:3 Changed 3 years ago by dsd

In my test I am using the Local schoolserver link each time, from new instances of Browse.

comment:4 Changed 3 years ago by martin.langhoff

Hm! If a new instance of Browse doesn't trigger it, but Browse sessions closed in a "deeper" URL /may/ have an old "sesskey" in the URL. The sesskey is a unique key, generated for each login session, that prevents CSRF.

If your browse session is closed/saved with a URL with a sesskey in it, upon reopening Browse, Moodle is likely to reset your session, and perhaps lose track of things.

Not all "deep" URLs will trigger this. You can scan the url for the string "sesskey".

comment:5 Changed 3 years ago by dsd

Tested again, with the following procedures:

  • Start browse (new session)
  • Click "schoolserver" link
  • Stop browse
  • Start brose (new session)
  • Click "schoolserver" link
  • Stop browse
  • Start browse (resume last session)
  • Moodle homepage loads without error
  • Click "add a new course"
  • Stop browse
  • Start browse (resume last session)
  • "Add new course" page loads without error
  • Go to google.com
  • Stop browse

Can't reproduce.

comment:6 Changed 3 years ago by dsd

Further test:

  • Open browse (new session)
  • Click "Local schoolserver" link
  • Click Browse's home button
  • Click "Local schoolserver" link

Still can't reproduce.

comment:7 Changed 3 years ago by reuben

This was hit 5/62 times in Chachapoyas.

comment:8 Changed 2 years ago by reuben

Report from Holmes running 12.1:

I tried a small experiment with reflashed laptops on first time boot, first time using browse, it seems like the problem with connecting to server was because laptops were not registered first.

  1. On one without registering to school server: requests username and password. Back to home, register to school server. Start new session of browse, still requests username and password.
  2. On another one registering to school server first: connects fine. If home page button or back buttons are pressed, and you try school server again, it requests username and password, but if you start a new session it works fine.

comment:9 Changed 2 years ago by reuben

Additional note:

Also notify whenever back button or homepage are used and you return to schoolserver same scenario with username and password shows up. Only solution is starting a new session on browse.

Note: See TracTickets for help on using tickets.