Re: [VuFind-Tech] UserAccount::catalogLogin()

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

I think I understand (though I have to confess that, being at Code4Lib and racing against time, I'm not giving this the thorough thought and deep reading that it probably deserves).  I know that some of the VuFind 2 code in this area has changed a bit -- hopefully for the better -- but I can't remember all the details.  When it comes time for you to reimplement this change on the newer version, let me know and we can discuss it further.  Perhaps what we need is to encapsulate this logic in a strategy class and register that as a "VuFind\CatalogLoginStrategy" service.  Most people will never need to change it, but in cases like this, it would give you a hook to replace just the important bits of the logic.  (Though of course there's also the question of whether the ILS drivers need extra/different parameters on the patronLogin method).

- Demian
________________________________________
From: Alan Rykhus [ala...@mn...]
Sent: Tuesday, February 12, 2013 10:11 AM
To: vuf...@li...
Subject: Re: [VuFind-Tech] UserAccount::catalogLogin()

Hello Demian,

I'm not sure what was intended with the design. I can say what I see
happening, describe how I see it currently working, and narrate how I
need it to work.

scenario 1. A patron clicks on a link that requires authentication.
There are a number of scenarios.
  a. There is no ILS and they authenticate against the mysql db
  b. They authenticate against their ILS
  c. They authenticate against some other db using LDAP, Shibboleth
    i.  these may be tied to the ILS
    ii. these may not be tied to the ILS

This to me is the patron login functionality.

scenario 2. A patron clicks on a link to see their loans, create a hold,
do something, etc. This is sometimes a second click, sometimes a result
of the first click.
 a. If it is after a patron authenticates and is a second click. In this
case a catalogLogin is done. catalogLogin in turn calls the ILS
patronLogin function, which was called when the patron authenticated if
they used the ILS in 1. So you end up authenticating the patron again.
And you have to maintain their credentials in the mysql db to do this.

While I can see this is needed in some situations, where you do not
maintain a persistent connection to the ILS, I have one where it is not
needed or wanted.

I've authenticated the patron, as long as their session is active I know
who they are. I have a key that gets me (or creates) the information in
the ILS. I do not have to log them on. In fact I can't log them on,
their authentication is based on a different patron db that has a link
to the same information but uses different credentials.

I don't think a flag is needed. I changed the code in User.php to call a
Catalog::catalogLogin function passing the User Object. In my driver i
just take the data from the User object and return it in a patron
structure. For those that actually need to do a patronLogin to their ILS
they can have catalogLogin call patronLogin in their driver. The result
is the same.

I'm not saying I like the solution, but for now I'm making the code work
and posting this out there for discussion. I'm not tied to what I've
done, the boss just likes results.

al

On Tue, 2013-02-12 at 00:19 +0000, Demian Katz wrote:
> Just to clarify what's going on and make sure we're on the same page:
>
> What catalogLogin() should be doing is checking to see if the user has
>  credentials stored in their account and using those to log in
>  automatically if so; otherwise, I believe it should lead to the user
>  getting prompted for barcode/password so that these credentials can be
>  stored.
>
> The reason patronLogin() gets called before the various user functions
>  is that we assume that they need information about the account which
>  comes through the login process.
>
> Would one solution here be to customize patronLogin so that if the user
>  logs in with LDAP, this is flagged in the session, and if the session
>  flag is found, the method is short-circuited to return whatever basic
>  information is needed to make all the other user functions work?
>
> - Demian
> ________________________________________
> From: Alan Rykhus [ala...@mn...]
> Sent: Monday, February 11, 2013 3:50 PM
> To: vuf...@li...
> Subject: [VuFind-Tech] UserAccount::catalogLogin()
>
> Hello Demian,
>
> I've been working on using LDAP for authentication and then using the
> ILS driver to do patron things with the ILS and have come across a
> design issue. I'm looking at supporting both the LDAP authentication and
> the ILS authentication.
>
> I only know for sure that the design issue exists in 1.3, because while
> I can find the templates for MyResearch in 2.0, I cannot find the code
> that calls them. (But then I haven't installed it yet and I was just
> browsing the code at SourceForge)
>
> In Aleph we have a Restful API. This API allows me to retrieve patron
> loans, holds, fines, bookings, and ILL requests. I can also renew,
> cancel, and create whatever where appropriate. I do not need to
> authenticate the patron to do these things, I only need their ID. Since
> the patron has to be authenticated before the links show up, that should
> be good enough.
>
> When I go to display the loans, holds, etc. the first thing that happens
> is that the UserAccount::catalogLogin() function is called. This in
> actuality logs the patron on again. I did not know of or have an issue
> with this before because I was using the ILS for authentication. The
> problem is that UserAccount::catalogLogin() calls Catalog::patronLogin
> with credentials stored in the MySQL DB. With the ILS authentication I
> was storing this information. With the LDAP authentication, I do not
> have or need this information.
>
> To me, these are 2 different functions and should not call the same base
> function down in the ILS Driver. It seems that the solution would be to
> have a Catalog::patronLogin and a Catalog::catalogLogin. In the ILS
> driver you could have the catalogLogin function call the patronLogin
> function if that is what is needed.
>
> One addition to this is that for those of us who do not need to login
> again, we do not have to store patron passwords.
>
> al
> --
> Alan Rykhus
> PALS, A Program of the Minnesota State Colleges and Universities
> (507)389-1975
> ala...@mn...
> "Be pleasant until ten o'clock in the morning and the rest of the day
> will take care of itself." ~ Elbert Hubbard
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Vufind-tech mailing list
> Vuf...@li...
> https://lists.sourceforge.net/lists/listinfo/vufind-tech

--
Alan Rykhus
PALS, A Program of the Minnesota State Colleges and Universities
(507)389-1975
ala...@mn...
"Be pleasant until ten o'clock in the morning and the rest of the day
will take care of itself." ~ Elbert Hubbard

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Vufind-tech mailing list
Vuf...@li...
https://lists.sourceforge.net/lists/listinfo/vufind-tech