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

Setting cookies inside GraphQL resolvers #361

Open
FOSSforlife opened this issue May 18, 2020 · 10 comments
Open

Setting cookies inside GraphQL resolvers #361

FOSSforlife opened this issue May 18, 2020 · 10 comments
Labels
documentation Requires a documentation update
Milestone

Comments

@FOSSforlife
Copy link
Contributor

FOSSforlife commented May 18, 2020

I've been attempting to use this tutorial (written using TypeORM and TypeGraphQL) as a guide for setting up authentication. He uses a "refresh token" method which he explains in this video, which is supposed to be more secure than relying just on JWT headers or cookies because it makes use of both.

In his code, he has a login mutation which, upon success, sets a refresh token using Express's res.cookie(). The problem with implementing this in Warthog is that the login mutation does not have access to the res object, as Warthog's context object only passes in req. The only place we can access res, as @goldcaddy77 has suggested, is inside the onBeforeGraphQLMiddleware and onAfterGraphQLMiddleware hooks. I'm just not sure how to get these hooks to run specifically when a user is logging in, since that's when I need to set the refresh token.

I also had the idea of passing res into the context object using the onBeforeGraphQLMiddleware hook, so that I could then access it from within GraphQL like the example shows, but this function doesn't seem to have access to the context object.

It doesn't seem like I'll be able to replicate the example I was looking at using Warthog, and if that's the case, I'd like to know the best solution for setting cookies inside GraphQL resolvers.

@goldcaddy77
Copy link
Owner

Gotcha! So it could be as simple as passing res in context as well?

https://github.com/goldcaddy77/warthog/blob/master/src/core/server.ts#L228

@goldcaddy77
Copy link
Owner

If that’s the case, feel free to open up a PR or I can get to it this week

@FOSSforlife
Copy link
Contributor Author

Yep! I'll go ahead and attempt implementing it myself :) Hopefully it's as straight forward as it seems.

@goldcaddy77
Copy link
Owner

Awesome. If you tackle this, let’s keep request there for backwards compatibility and additionally add req and res.

@FOSSforlife
Copy link
Contributor Author

Right, I forgot that request was named as such here instead of req. In that case, I'll just do request and response if that works with you.

@goldcaddy77
Copy link
Owner

I’d prefer req and res to indicate they’re the express req and res objects.

@FOSSforlife
Copy link
Contributor Author

Sorry for not making progress on this yet, I keep getting super wrapped up in work and other priorities. I should have time this weekend, but if anyone else wants to take care of it sooner I'm also fine with that. Otherwise I'll get to it on saturday.

@goldcaddy77
Copy link
Owner

No worries, I’ll review once I see a PR come through

@goldcaddy77 goldcaddy77 added the documentation Requires a documentation update label Aug 18, 2020
@FOSSforlife
Copy link
Contributor Author

Hey @goldcaddy77, sorry for not keeping you posted. I had started to make progress on this, but didn't have anything working. I don't think I'll be able to accomplish this task, as I've got many other things going on and have currently de-prioritized my project which was using Warthog. Hope you understand and sorry to disappoint.

@goldcaddy77
Copy link
Owner

No worries - I'll take a crack at this when I get through the other items on my list.

@goldcaddy77 goldcaddy77 added this to the V3 milestone May 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Requires a documentation update
Projects
None yet
Development

No branches or pull requests

2 participants