Currently, the code base presumes a session. Our organization makes use of lazy sessions wherein public access is granted to a page, but additional content is exposed on that same page to those who are logged in.
I don't know if you would call this a bug, or more likely an enhancement request, but it seems impossible for this plugin to authenticate on a server employing lazy sessions.
To begin, the controller starts the idpAuthorize function by grabbing $email from $_SERVER on line 110.
And so the controller returns nothing and the user faces a blank white screen. No redirect, no login, just broke.
What strikes me as buggy about this is that the user is created on line 146before redirecting to the IdP endpoint on line 167. So I'm not positive, but it doesn't seem possible for the IdP redirect to ever occur.
I already have an open PR #25 that brings it up to speed with Laravel 5.4, and I will most likely add commits to address this issue next week as it's a requirement for a project I'm currently working on. But I wanted to raise this now to get any feedback before I attempted to tackle the issue.
Thanks for all your work on this project thus far - it's been a delight to use :smiley:
Currently, the code base presumes a session. Our organization makes use of lazy sessions wherein public access is granted to a page, but additional content is exposed on that same page to those who are logged in.
demo
e.g. if you're running Apache, then your config might contain this:
I don't know if you would call this a bug, or more likely an enhancement request, but it seems impossible for this plugin to authenticate on a server employing lazy sessions.
To begin, the controller starts the
idpAuthorize
function by grabbing$email
from$_SERVER
on line 110.There's some logic in
getServerVariable
that inevitably returnsnull
without a shibboleth session set.Side question: What is the purpose of the
REDIRECT_
prefix on server variable names? I haven't encountered this before.Next, because
$email
isnull
it obviously fails the first conditional.Finally, there is an
else
with a nested failing conditional.And so the controller returns nothing and the user faces a blank white screen. No redirect, no login, just broke.
What strikes me as buggy about this is that the user is created on line 146 before redirecting to the IdP endpoint on line 167. So I'm not positive, but it doesn't seem possible for the IdP redirect to ever occur.
I already have an open PR #25 that brings it up to speed with Laravel 5.4, and I will most likely add commits to address this issue next week as it's a requirement for a project I'm currently working on. But I wanted to raise this now to get any feedback before I attempted to tackle the issue.
Thanks for all your work on this project thus far - it's been a delight to use :smiley: