Add first concept for link-sharing #1831
Conversation
| - the shared data will be live (as opposed to "freezing" the data to the time of link creation) | ||
| - link format is `.../<code> (can't use `.../bases/X/statviz`: insecure because it's easy to navigate to other bases and view their data; also not unique (can't expire)) | ||
| - the expiration time of the link is one week. Later we can make is customizable, and/or add an action to invalidate a created link | ||
| - we expose the public app in the `api` GAE service. Hence it won't interfer with the main `app` service |
There was a problem hiding this comment.
Is this already the case? Or something we're doing specifically for link sharing?
There was a problem hiding this comment.
No, we're not doing this yet. It's a suggestion for the link-sharing use case.
|
|
||
| - there has to be a new action-based permission to allow link-creation for certain usergroups | ||
| - there has to be a public FE and a public GraphQL endpoint to fetch data | ||
| - the public FE is hosted under `api.boxtribute.org/shared` and deployed with the `deploy-api` CircleCI job (depends a new `build-statviz` job) |
There was a problem hiding this comment.
can you share context on why you're suggesting this? It seems strange to me to host the FE on what appears to be an API endpoint?
There was a problem hiding this comment.
I suggested this for simplicity (less devops effort because we don't need to establish a new subdomain nor any new GAE services). The endpoints we currently have for the api subdomains are the GraphQL one at / and the documentation at /docs.
For a separation of concerns it probably makes sense to have a dedicated subdomain for link-sharing.
There was a problem hiding this comment.
@pylipp got it. Is there any other way we can achieve that? If the back end link sharing is going to be part of the standard API on the api subdomain, then any reason the link sharing can't just operate as part of the same FE code base? Or am I misunderstanding here?
| ### Open questions | ||
|
|
||
| - how do avoid misuse of the link, or the exposed public GraphQL endpoint (DDoS mitigation)? | ||
| - can FE resolve a URL like `.../<code>` into a route like `.../<code>/bases/X/statviz` on the FE **and** process the returned data as if it was a GraphQL response? |
There was a problem hiding this comment.
when you say resolve, does the FE actually need to map to a different route? Is it just crafting a graphql query directly? I wasn't clear why the FE would need to "process the returned data as if it was a GraphQL response?" - or specifically, why it therefore wouldn't be a graphql response in the first place?
There was a problem hiding this comment.
We (Hans, Felipe, me) talked about this yesterday; it seems to be feasible but requires adjustments to existing queries.
I'll try to explain it like this: in v2, when the user visits e.g. /bases/2/statviz, it will load the page and send a GraphQL request to the BE. A GraphQL response is returned and used to build the page.
For the scenario of link-sharing I was thinking whether the following is possible:
- user visits link at
.../<code> - FE sends request incl the code
- BE checks the code. Since it has saved the type of requested data at the time of link creation, it can now look up the data and return it in the response, incl the corresponding route for FE
- FE goes to the returned route and plugs in the returned data (instead of issuing another GraphQL request)
You can see this as a mind experiment of mine rather 😄 does it make sense to you?
The approach we agreed on is different though:
- FE sends request with code
- BE validates code and sends metadata route
- FE goes to route and runs GraphQL queries to fetch data
|
|
||
| ### Open questions | ||
|
|
||
| - how do avoid misuse of the link, or the exposed public GraphQL endpoint (DDoS mitigation)? |
There was a problem hiding this comment.
Could look at rate limiting server side based on the link hash being passed in. Could also consider https://cloud.google.com/armor/docs
pylipp
force-pushed
the
draft-for-link-sharing
branch
from
df7f4b5 to
df392c6
Compare
|
@jamescrowley , would be interested in getting your input with all the findings made by the team, especially for the password pusher library (or suitable alternative). |
There was a problem hiding this comment.
LGTM, would like to hear more technical commentary on @jamescrowley from the answer, and both @jamescrowley and @HaGuesto on PP analysis.
Rendered document.
It got more detailed in the BE part. For the UI it's rather some questions/ideas.
LMK if parts are not clear.