Skip to content

increase complexity of security example #992

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

Closed
xenoterracide opened this issue Jun 7, 2024 · 1 comment
Closed

increase complexity of security example #992

xenoterracide opened this issue Jun 7, 2024 · 1 comment
Labels
status: invalid An issue that we don't feel is valid

Comments

@xenoterracide
Copy link

xenoterracide commented Jun 7, 2024

I went looking through https://github.com/spring-projects/spring-graphql/tree/1.0.x/samples/webmvc-http-security/src/main which is linked from the reference docs. I'm left with some questions.

How does it look to add the more or better yet less secured methods? for example, how would I have a mutation that doesn't require authentication at all, while everything else does? user self registration be a common exception to the rule. Another thought I've had on this is can I have more than one graphql endpoint (secured/insecure).

Not sure if there's a way to resolve a secured result differently from an insecure one (that's sounds rat nesty). However, a good example here is Bob queries my user info vs Me querying it. I'm fairly confident this can't be done by having multiple @Query methods (but what if it could, cool feature).

I don't know yet how spring-graphql exposes a schema, but assuming it's generated, or can be, at runtime, how does securing something modify that.

I'm considering that perhaps I should just make a registration and any other insecure resources non graphql... but that's another thing.

I'm sure I can figure this out, but samples of using @Secured, etc, even in the reference documentation might be nice. Possibly documenting what to expect if you do a complex query that accesses some insecure path and a secured one. I'm not exactly certain what this would generate as a response.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jun 7, 2024
@bclozel
Copy link
Member

bclozel commented Sep 23, 2024

Closing as this issue is not actionable on our side. We'll work on sample in #208

@bclozel bclozel closed this as not planned Won't fix, can't repro, duplicate, stale Sep 23, 2024
@bclozel bclozel added status: invalid An issue that we don't feel is valid and removed status: waiting-for-triage An issue we've not yet triaged labels Sep 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: invalid An issue that we don't feel is valid
Projects
None yet
Development

No branches or pull requests

3 participants