search

ivoa-std / DataLink

DataLink standard (DAL)
3 stars 6 forks source link

Some links in the {links} table may have restricted acces. Trying to access them gets a 403 error message.. #33

Closed Bonnarel closed 3 years ago

Bonnarel commented 4 years ago

We could add a non-normative advice to include a column in the {links} endpoint named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. This issue has been raised By Pat Dowler in May. I (FB)don't know exactly how to write this change proposal. So I didn' create a pull request attached to this.

robyww commented 4 years ago

This is a good idea.

lmichel commented 4 years ago

Good point. But you cannot say that an authenticated endpoint is not readable (readable=false). Something like access=open|restricted might do the job.

pdowler commented 4 years ago

The link (access_url or service_def) to which this applies is typically a specific file. The way we implemented this is that the readable column contains true if the user will be authorized to use the link within the context if their current authentication - that is, it actually predicts that authentication is required and that the user will be authorized to access the resource. However, we have a fine-grained A&A system that supports anonymous access to public data and authorized access to proprietary data.

So there are really two things here that we combined in our readable field:

  1. telling the client that authentication will be required is the first and probably simpler part; this mainly saves anonymous callers from trying a URL and getting a 401 (challenge to authenticate) or 403 (permission denied)
  2. predicting that the user will be authorized is more demanding to implement; this mainly saves authenticated callers from having to try a URL and getting a 403 (permission denied)

We have used this primarily as a way for our main web UI to know when to offer the caller download links or check boxes to select data for download.

pdowler commented 4 years ago

A single field would suit me, but it could be prudent to have one field that says whether authentication is be required and a separate field to predict authorization in order to not make implementing too hard or impossible (it depends on what other infrastructure and content one has).

If a particular service only has "public" resources that can be accesses anonymously or they cannot predict authorization then they could just add the former. If a service can predict then they could include the second field to further help clients avoid trying URLs that are not going to work.

Both would help client s/w know when to offer the option to authenticate or to change authentication.

pdowler commented 4 years ago

I volunteer to propose changes and modify the document.

pahjbo commented 3 years ago

This change seems entirely superfluous - the WWW is full of links that might resolve to give a 403 status - that is all part of the stateless HTTP protocol clients should expect that possibility. I am not sure that the client can usefully make any decisions knowing the information presented - anyway 403 is supposed to indicate that the access is forbidden despite authentication - 401 is used to indicate that authentication might make a difference.