[Koha-bugs] [Bug 30962] REST API: Add endpoint /patrons/:patron_id/check_password

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

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

--- Comment #17 from David Cook <dcook at prosentient.com.au> ---
(In reply to Tomás Cohen Arazi from comment #16)
> (In reply to David Cook from comment #12)
> > Are all the existing API tests in "t/db_dependent/api/v1/"?
> 
> Not sure what you mean here, but we try to enforce 100% code coverage on the
> tests.

Are good examples of API tests found in that location?

> > > 2. Route's name should not be a verb (/password/validation maybe?)
> > 
> > I did struggle to come up with a noun for this one so I take the point. 
> 
> I'd go with 'validation'.

In light of the /api/v1/auth/* routes that we have these days...
/api/v1/auth/validation?  

Or do we want another path prefix in there like "password" for
/api/v1/auth/password/validation?

And we'd be posting userid and password to that endpoint. 

--

I'm currently using /patrons/:patron_id/check_password and when I implemented
bug 31982 locally it did cause a problem because I was using the OPAC
interface. I switched to the Staff Interface API and then it was all good. 

In my case, the consumer of this API is Keycloak, which also runs locally. If
it was a third-party system, I think I'd need to create an security exception
to allow it through to that endpoint. 

I keep thinking about public vs non-public APIs... and I figure public APIs are
things that every day people and front-end systems should be able to use. They
offer the same functionality to the public as the OPAC but they do so in a
machine-friendly way. If an action is only allowed by staff, it's part of the
non-public admin API. And if there's a third-party system that needs to access
that, because we trust it, then we make an explicit exception for it, and
ideally keep the scope narrowed to just what it needs.

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