https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28317
--- Comment #32 from David Cook <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
