[Koha-bugs] [Bug 28317] Remove CGI::Session::Serialize::yaml dependency by using the default serializer

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28317

--- Comment #32 from David Cook <dcook at prosentient.com.au> ---
(In reply to Kyle M Hall from comment #29)
> Wouldn't it make more sense for your to add an API endpoint for outputting
> deserialized session info? That way you aren't messing with Koha's
> internals, which are subject to change.

I shouldn't have said third-party apps, as they're not really third-party.
They're just non-Koha apps served off the same domain. 

Regarding your question, yes and no.

1. No:
Firstly, everything is subject to change. I've seen API integrations break when
the API endpoint gets updated. In this case, I can see Koha changes coming, and
the code can get updated. Plus, the sessions are fairly stable overall (when
serialized as YAML at least). It's not a drama. 

Secondly, at the moment I can use the session without any local customizations
to Koha. 

2. Yes:
If I were to use an API endpoint, it would require customization, and I
probably wouldn't create an endpoint outputting session data. Instead, I'd
probably make multiple API endpoints to get the specific data that I need (like
effective user permissions). 

In this case, I have access to the CGISESSID cookie, so I have the session ID,
and Koha is working kind of like a SSO system. If I were to use an API, I would
need an endpoint that could convert a session ID to a borrowernumber. But then
Koha doesn't have any authorizations/permissions that would really be
appropriate for that kind of administrative process. 

And I would consider it an administrative process. As such, I wouldn't love the
idea of it being part of Koha's public Internet-accessible API. I would want to
lock down that API endpoint within a separate Koha Admin API which could be
limited to specific IP addresses or a local network. 

Koha also doesn't have a concept of "system users" that are reserved just for
API user (and which can't be deleted by library staff). 

So... while using an API might make sense... it would be a tonne of work. Much
more work than just reading the session from the database. 

--

At the end of the day, I imagine we'll switch the serializer to default, and
then I'll have to think up some kind of hacked together API solution. Or scrap
the other apps. 

Koha really needs an administrator level above superlibrarian, or some other
management interface. But it all takes considerable work.

-- 
You are receiving this mail because:
You are watching all bug changes.