https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30962 --- Comment #17 from David Cook <dcook@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.