Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to upload query #2

Open
Pasqualle opened this issue Oct 17, 2018 · 9 comments
Open

Option to upload query #2

Pasqualle opened this issue Oct 17, 2018 · 9 comments

Comments

@Pasqualle
Copy link

We would like to use persisted queries, but not automated. It gives us a security benefit, that only the selected queries are allowed for clients.

  1. Option to add/upload queries manually, similarly as in graphql module (https://www.drupal.org/docs/8/modules/graphql/query-maps)
  2. Add an option to disallow unknown queries

Note: Using the persisted queries option provided by the graphql module is not wanted, as it works with a deprecated apollo package. apollographql/persistgraphql#67

@lucasconstantino
Copy link
Contributor

I think what you are trying to accomplish should be addressed by the core graphql module, as none of it has to do with the concept of apq.

@Pasqualle
Copy link
Author

I have discussed this earlier with Sebastian, and he suggested to open a PR against this module. I just wanted to be sure that we all agree on the solution.

As I mentioned the problem with the core graphql module is that it relies on an apollo package which will be deprecated. So there is only 1 apollo package apollo-link-persisted-queries which is usable, and your module works with that package. Therefore I should use your module or fork your module to achieve non-automated persistent queries.
The current persisted queries solution in graphql core, the part which is related to the deprecated apollo package, should be moved into separate module in case someone is still using it. It should not be the recommended way to do persisted queries.

Therefore my suggestion is to make this module work with non-automated way also, then advertise it as a recommended solution to do persisted queries.

@lucasconstantino
Copy link
Contributor

I see your point. It is a bold move, though, and we should sync efforts with the graphql-core team. As of for now, this module states clearly it's meant only for Automatic Persisted Queries, so if we intend to change it, probably a fork would fit better than simple pull-requests, you see what I mean?

@Pasqualle
Copy link
Author

I have asked for more comments on this on the slack channel.
As I will need this functionality I can do it as a fork no problem..

@lucasconstantino
Copy link
Contributor

@Pasqualle nice! Perhaps the code related to APQ becomes a submodule of that fork one day ;)

@sebas5384
Copy link
Collaborator

@Pasqualle with @lucasconstantino we develop a concept using a secret to encrypt de query hash, so in that way you can validate it before you "upload" the missing pair of hash and query on the server.

Here's a draft showing the approach:
persisted queries with secret

@Pasqualle
Copy link
Author

I was thinking about this secret approach. As I understand it correctly the client must know the secret (need to know how to create the valid hash). That would mean it is not fully secure as new queries are allowed if someone extracts the secret from the client.
Or you have a different client which knows the secret and is not public.

@lucasconstantino
Copy link
Contributor

lucasconstantino commented Oct 20, 2018

We parse the queries on build time, thus having the "client" secret not actually know by the client application. There are both Babel plugins and webpack loaders that can help, depending on which you are used to.

@sebas5384
Copy link
Collaborator

@Pasqualle I guess @lucasconstantino already answered your doubt about exposing the secret.
We are using three libraries on the frontend:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants