View Issue Details

Jump to NotesJump to History
This bug affects 1 person(s).
 8
IDProjectCategoryView StatusDate SubmittedLast Update
12083Bug reportsOtherpublic2017-01-25 20:082017-01-31 13:32
Reporterasshank Assigned Toc_schmitz  
PrioritynoneSeverityminor 
Status closedResolutionno change required 
Product Version2.62.x 
Summary12083: one time password not working (anymore) (on IE11 and Edge)
Description

I try to use the one_time_password feature (after a long time again).

But I can't get it to work anymore.

Steps To Reproduce

  1. In config.php:
    'config'=>array(
    'use_one_time_passwords' =>true,
    )

  2. External application writes a md5()hashed password in the lime_users table.

  3. linking to limes /index.php/admin/authentication/login?user=name&onepass=secret

  4. No login..

Additional Information

I obsurve that step 4. does delete the one_time_pw blob.

When config 'use_one_time_passwords'=>false
The one_time_pw blob is still there. So 'use_one_time_passwords'=>true does have effect!

I remember that this behaviour is a long time bug! Not just in this current version.

TagsNo tags attached.
Bug heat8
Complete LimeSurvey version number (& build)2.62.0 170124
I will donate to the project if issue is resolvedNo
Browserall sorts
Database type & versionmysql
Server OS (if known)centos7
Webserver software & version (if known)apache
PHP Version5.4,x 5.6.x and 7.0x

Users monitoring this issue

aesteban

Activities

asshank

asshank

2017-01-25 20:53

reporter   ~42839

About browers:

IE11 and Edge are not working!!!!

Chrome 55, Firefox 51, Opera 12.16, Opera 42, Vivaldi 1.6 are working.
asshank

asshank

2017-01-27 11:19

reporter   ~42845

After further testing: Other browsers have the same issue. Bare with me.

Apparently it works only when a new browser session is used.
The browser session that has written the one_time_pass seems not to be able to login in.

I have made a plugin with an afterSuccessfulLogin event. It fires in a new session.. hence you are logged in succesfully. But does not fire when in same session, so login failed. As said before. the one_time_pass is deleted! So at some stage there is a successful login.. but later on it is not OK.

Very hard to debug.. But I'm doing my best!
asshank

asshank

2017-01-27 11:21

reporter   ~42846

So olle: Summary 'one time password not working (anymore)' seems correct!
asshank

asshank

2017-01-27 11:22

reporter   ~42847

@olle: Summary 'one time password not working (anymore)' seems correct!
asshank

asshank

2017-01-27 11:57

reporter   ~42848

afterFailedLoginAttempt event is not triggered either.
asshank

asshank

2017-01-27 12:14

reporter   ~42849

beforeLogin is triggered when:
in same browsersession (thus login is going to fail)
but when in new session, so login wil be a success, beforeLogin is not triggered (curious!?)
asshank

asshank

2017-01-27 12:19

reporter   ~42850

So somewhere in core plugin beforeLogin is something going wrong?

in admin/authentication.php it states:
// In Authdb, the plugin event "beforeLogin" checks if the url param "onepass" is set
// if yes, it will call AuthPluginBase::setAuthPlugin to set to true the plugin private parameter "_stop", so the form will not be displayed
// @see: application/core/plugins/Authdb/Authdb.php: function beforeLogin()

So I'm going into application/core/plugins/Authdb/Authdb.php to see what is going on...
asshank

asshank

2017-01-27 14:35

reporter   ~42851

Overall: IMHO it just does not work in same browser session.

Hard to debug.

IE11, Chrome, Firefox tested.. same problem.
asshank

asshank

2017-01-28 01:29

reporter   ~42858

After a lot of testing I came to this conclusion:
When working in a browser session and the application is linking to a one-time-password admin login it does not login in. But also the entire session (PHP) of this browser session is destroyed.

So for instance: One is logged into a webapplication (parent) that is providing a link to login to limesurvey/admin via one-time-password (child) will fail, and as a consequence destroys the session.
So when coming back to the parent application you are logged out also (if the login is based on the existing of php sessions) in my case).

This behaviour is whitnessed in all major browsers.
asshank

asshank

2017-01-29 15:08

reporter   ~42860

@olle More testing reveals: IE and Edge (on windows) are the problem.. So you can change the Summary again.

https://connect.microsoft.com/IE/feedback/details/810700/subject-ie11-is-losing-cookie-information-and-thus-becoming-detached-from-a-web-application-session

When starting a new window/tab in IE and Edge.. a new session is created but in that new window there are two PHPSESSID cookies. The one from the parent and a new one. That seems to be the problem.

Very hardcore :-(

When doing the same in Chrome/Opera/Firefox the new windows contains only the new PHPSESSID cookie. And because there is only one PHPSESSID cookie there is no confusion in choosing the right one. In IE and Edge there is!
ollehar

ollehar

2017-01-30 10:10

administrator   ~42865

Wow, OK. Complex.
asshank

asshank

2017-01-30 19:05

reporter   ~42886

Next thing I will do is a server-side change of the PHPSESSID cookie name in PHP.INI. Because there are two 'PHPSESSID' cookies, IE and Edge can not keep them apart.

The server will then generates a different Cookie (session.name=DIFFERENTSESSID for the app that is calling lime with one_time_pass. Then the brower can take the right one (just the only PHPSESSID cookie in the browser.

Hopes this workt out.. And a note can be added to the documentation of limesurvey..

Stay tuned... :-)
c_schmitz

c_schmitz

2017-01-30 19:52

administrator   ~42889

I cannot reproduce. One-time passwords have been working for us for a long time.
asshank

asshank

2017-01-31 00:24

reporter   ~42892

It works.. session.name in php configuration on server set to another name for the parent app! Now One-time passwords works!

Facit: IE and Edge stacks the session cookies in child windows. And cookies with the same name are thus in conflict.
Other browsers have child windows without cookies and thus build there own when needed.

That was a tough cookie!

@c_schmitz If you like I can reproduce this behaviour by sending you a link to our parent application (sometime tomorrow :-)
c_schmitz

c_schmitz

2017-01-31 10:11

administrator   ~42894

I don't think should be considered a bug.
asshank

asshank

2017-01-31 13:32

reporter   ~42905

Correct. Not a bug on the limesurvey part. More a Client problem/bug.

Maybe it should be mentioned in the documentation

Issue History

Date Modified Username Field Change
2017-01-25 20:08 asshank New Issue
2017-01-25 20:53 asshank Note Added: 42839
2017-01-27 10:28 ollehar Summary one time password not working (anymore) => one time password not working (anymore) (in IE11 and Edge)
2017-01-27 11:19 asshank Note Added: 42845
2017-01-27 11:21 asshank Note Added: 42846
2017-01-27 11:22 asshank Note Added: 42847
2017-01-27 11:25 ollehar Summary one time password not working (anymore) (in IE11 and Edge) => one time password not working (anymore)
2017-01-27 11:57 asshank Note Added: 42848
2017-01-27 12:14 asshank Note Added: 42849
2017-01-27 12:19 asshank Note Added: 42850
2017-01-27 14:35 asshank Note Added: 42851
2017-01-28 01:29 asshank Note Added: 42858
2017-01-29 15:08 asshank Note Added: 42860
2017-01-29 21:04 aesteban Issue Monitored: aesteban
2017-01-30 10:10 ollehar Note Added: 42865
2017-01-30 10:10 ollehar Summary one time password not working (anymore) => one time password not working (anymore) (on IE11 and Edge)
2017-01-30 19:05 asshank Note Added: 42886
2017-01-30 19:52 c_schmitz Note Added: 42889
2017-01-31 00:24 asshank Note Added: 42892
2017-01-31 10:11 c_schmitz Note Added: 42894
2017-01-31 12:55 c_schmitz Assigned To => c_schmitz
2017-01-31 12:55 c_schmitz Status new => closed
2017-01-31 12:55 c_schmitz Resolution open => no change required
2017-01-31 13:32 asshank Note Added: 42905
2021-08-02 16:37 guest Bug heat 6 => 8