[OPEN-ILS-DEV] PATCH: srfsh.c (treatment of login_session)

[Mike Rylander]

On 7/22/07, Scott McKellar <mck9 at swbell.net> wrote:
> This patch adds some minor functionality, and tidies up the treatment
> of the login_session variable.

Applied
[snip]

> -----------
>
> As I worked on this patch, I noticed that there is no simple way
> to log out, and then a thought occurred to me.  What happens if
> we're logged in and then we log in again, possibly with a different
> username and/or password?  What if the second login is unsuccessful
> -- does the first login remain in effect?  Or do things just get
> terribly confused?

Nothing particularly bad happens.  The client forgets about the first
session and the server expires it after a while.

>
> I don't see any obvious attempt to log out from a previous login,
> but I also don't know what such an attempt would look like if it
> were there.

There's a method in the auth server for that, so a direct call would
look something like

  srfsh# request open-ils.auth open-ils.auth.delete "authtoken"

While we're on the topic of the auth server, I just thought I'd throw
out there that I think we should remove the login functionality from
srfsh proper.  It depends on an open-ils app, so it's wrong to ship in
the base opensrf distro.

That being said, it's much easier to use than doing the login dance by
hand.  Therefore I propose we create a simple plugin system.
Basically, we just add an element to the config file for srfsh that
allows for the specification of plugin commands via shared objects.
Imagine this in the config:

  <extention implementation="/openils/var/lib/authlogin.so" command="login"/>

srfsh would then dlopen the named implementation and when it saw a
command it didn't understand natively, but for which there was a
registered extention, it would call a function by the name of, say,
handle_extention in that dlopened lib, and the the function would be
required to have a definition of

int handle_extention( char* words[] );

where the words[] array is the same as is used by all other handle_*
methods (with the exception of handle_request, which gets a relay int
(flag?)).

For the login functionality, we can basically just move handle_login
to its own module (in the ILS svn), change the function name and
compile that against libopensrf.

Eh? Thoughts?

--miker