search

paleobot / pbot-dev

Codebase and initial design documents for pbot client
MIT License
2 stars 2 forks source link

Protected site check box functionality #134

Closed doricon closed 11 months ago

doricon commented 1 year ago

Protected site check box: does this functionally do anything yet? If you check protected, but the collection record is public, is the gps visible to folks that pull up the record? It will be important to know this for the hack-a-thon so we can tell folks that may be concerned about their data.

NoisyFlowers commented 1 year ago

Who should be able to see the GPS coordinates, once a protected site is made public? Anyone who is logged in?

aazaff commented 1 year ago

@NoisyFlowers Dori is going to put a more lengthy response to this shortly, but the immediate answer is just punt on this issue entirely for now. I'm de-tagging it for the hackathon.

doricon commented 1 year ago

Andrew and Dori discussed briefly - we need a Botany pow-wow to decide style. Option: -fuzzy your own data -hide GPS data altogether (not a good option) -other option?

For now, the protected button is tag but doesn't actually do anything. We should advise folks to keep in private bench for now.

NoisyFlowers commented 1 year ago

Ok. Notes for the future:

Providing the gps coords of protected public sites to logged in users would be the easiest option.

There is an @isAuthenticated schema directive in neo4j-graphql-js: https://github.com/neo4j-graphql/neo4j-graphql-js/blob/master/docs/neo4j-graphql-js-middleware-authorization.md that is supposed to work at the field level. However, it is provided by a deprecated package: https://www.npmjs.com/package/graphql-auth-directives. This, in itself wouldn't be a problem; neo4j-graphql-js is deprecated but we use it. The problem is that it doesn't seem to work well.

After some futzing around, I was able to get it to compile and run. When I hit a direct collection result page with a request that includes an auth header (e.g. logged in user), I received the gps coords in the results. But when I hit the same url with a request that does not include an auth header, I get an error from the server that there is no auth header. Well, duh. This user is not logged in. Expected behavior is that I should get the direct query results page with the fields that have the @isAuthenticated directive blank. That would seem to be the whole point of a field-level directive.

So, the easiest case looks like it could be a little ugly.

Anything more fancy (levels of access or whatever) will get worse fast.

ecurrano commented 1 year ago

I don't want to close this yet, since there is useful information here, but we have decided to retain this box simply to hold the information of whether the site is protected or not and to make it the responsibility of the user to make coordinates sufficiently fuzzy to satisfy regulations. Our instructions link to the SVP document with best practices for reporting locality data.

ecurrano commented 11 months ago

I think this is all adequately addressed now in our cheat sheet and directions that the user is responsible for making the GPS coordinates fuzzy enough to satisfy rules and courtesies. I am closing this issue.