-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
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. |
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. 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. |
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? |
I have asked for more comments on this on the slack channel. |
@Pasqualle nice! Perhaps the code related to APQ becomes a submodule of that fork one day ;) |
@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. |
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. |
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. |
@Pasqualle I guess @lucasconstantino already answered your doubt about exposing the secret. |
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.
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
The text was updated successfully, but these errors were encountered: