[Koha-bugs] [Bug 28157] Add the ability to set a library from which an API request pretends to come from

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

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

--- Comment #17 from David Cook <dcook at prosentient.com.au> ---
(In reply to Tomás Cohen Arazi from comment #16)
> The catch is, the API is stateless. If it being used from a browser with a
> session cookie, then we're are all set. But the API is not designed with
> that only use case in mind.
> 

I find the word "stateless" to be a bit misleading. 

The only difference between the OAuth token and the cookie (with a session ID)
is where the state is stored. With the browser cookie, we let people specify
the library they want. You could do the same thing with the OAuth token. When
you make the token request, you could request a particular scope that would
grant you access for a particular library.  But... we don't use OAuth scopes,
so we don't currently have that ability.

Plus... we also support Basic auth which doesn't carry any state so fair
enough. (Of course, with the basic auth, we could actually have a login
endpoint where someone specifies a branch and it returns a JWT that they use
going forward, but oh well.)

I'll concede the point.

> > I suppose an alternative would be to pass the target branch in parameters
> > but that would only work for certain endpoints.
> 
> The header is a parameter he he. If you mean query parameters, they are
> expected to be used for filtering purposes in a Restful design.

I was referring more so to the data sent to the particular endpoint. But I was
working off abstract ideas and no concrete examples. I was thinking in terms of
posting a JSON object to the API and one of the keys being the branch, but yeah
it wouldn't be particularly RESTful.

Personally, I find REST to be a broken concept. Last time I looked at the API,
it wasn't RESTful in many ways, although that was a while ago. I find REST to
be too dogmatic to be practical anyway though.

> This dev is actually written to solve a very concrete problem we noticed
> with extended attributes routes. Extended attributes visibility and
> setability are by design (in Koha) something that depends on the current
> library. Look at Koha::Patron::Attributes->filter_by_branch (don't remember
> the exact name, on the phone).
> 

That's still fairly abstract. What's the particular use case? (Also I couldn't
find the method that you mentioned...guessing it must be something different.)

With the example of the patron attribute branch limitation... is the idea that
an API user has requested a list of available patron attributes and it should
be limited by a branch? In the browser context, that's their login library. I
can't think of a user-specific non-browser context.

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