First of all the project is amazing, I had GraphQL working with MongoDB very quickly. Even GraphiQL with the ModHeader extension. However, I am trying to add policies to the graphQL endpoints and I am finding that ctx.session is always empty, even tho I am making authorized requests (via the Bearer token)
How does session work in this example? Do I need to query for the user every single time I create a request?
The user info is available through the ctx.state.user object and not the ctx.session. Also, feel free to take a look at the GraphQL example https://github.com/strapi/strapi-examples/tree/master/react-apollo
Related
So I am creating some api's on Laravel using Passport (JWT).
I am having issues deciding what is the preferred method for the following:
PUT: api/users/{user_id}
PUT: api/users/me
I need the api so that the user can change his own information, but I would also like it for the api to be accessible for the Admin to change said information.
At the moment I am only using the first API and checking if the ID is the same as the one in the JWT auth or if the one requesting the api is the Admin.
But I was also thinking that maybe it was better to have them separate. The first api should only be accessible to the Admin, and I should be taking the ID from the JWT auth for the second api.
What would be the correct choice? Or is there a better choice?
I would say using this approach is better:
PUT: api/users/{user_id}
That allows anyone to consistently link to your own profile or to some other user profile in the same way. Then depending on your authentication and authorization, you can be allowed to do different operations on that resource.
There is no correct or better choice. You seem to understand the implications of using any of them so it's really up to you to choose. With the /{user_id} version you have to be extra careful not to remove proper validation rules from your code. If you used /users/me for a GET operation you would have to be careful with setting cache headers. If a browser would cache a response to users/me and then another user would request this endpoint, then you could get some other user's data. For PUT operations, though, this is not a concern.
I want to use artillery.io as a stress-testing tool, and want to setup a basic stress-test. But all my url's are behind an auth wall (using Auth0) and I want to try to get a valid token for the testing session so that my backend does not throw me into a 401-spiral. The artillery docs explains that I can hook up to some lifecycle events using processor, but does not explain which lifecycle hooks I have available. I've managed to figure out that there is a beforeRequest hook I can use, but this does not seem optimal as this will probably run before every request. My tokens have at least an hour validity...
So the main question is; how do I construct a processor hook which taps into the auth0 login flow, retreives a token which can then be stored in an environment variable (or some other local mechanism) for use as an Authorization Bearer token in future requests done by artillery?
OR if this is a bad pattern to follow, what is the best practice for urls behind auth-walls? I've already thought about loging in first and then copying the token to an environment variable and use that, but this makes the test a bit harder to use since it requires a manual step.
Any input is greatly appreciated.
I'm using Vue with OvermindJS (instead of Vuex) for state management. Within Overmind, I use GraphQL following this tutorial from their official docs. It works like a charm, but I run into a problem with the authentication. I use a JWT approach with a refresh-cookie. That means I need to refresh the Token at certain intervals or when it's expired.
I think an interceptor that can check if the token is expired every time I make a request to my GraphQL endpoint would be the best approach. Is this possible in Overmind? Alternatively, I could create a Promise function to every created request that checks it, but I don't find that solution particularly appealing.
Cheers
I'm implementing the Socrata API to be able to parse publicly-available data from the City of Chicago open data set. I am really just concerned about the data itself, so I did not initially think that I would need to implement OAuth2 through an app exposed via ngrok to be able to GET the data.
My initial attempt was to take the GET requests mentioned in their documentation and try to get responses through Postman.
Here's an example of such an attempt:
I also added my Socrata App Token as a param in the querystring, but the same message was shown.
So I tell myself, ok, maybe they deprecated GET requests without making the client go through OAuth2. If they didn't deprecate these GET requests, I would prefer not to have to deal with OAuth2, but I began implementing the authentication process and everything went successfully until I got to the following instructions found here:
I have every single value that needs to be included in that POST request except for 'authorization_type'. Where does this come from? I tried leaving 'authorization_type' in as a string, but received a response similar to the 'Invalid username or password' message in the top image in this question.
Are you only accessing public datasets from Chicago's data portal? From your screenshot it looks like you're trying to access the Building Permits dataset, which is public.
Authentication is only required for modifying datasets or accessing private data, so chances are very good you don't even need to authenticate. Just include an application token with your request for throttling purposes.
Glad to help you figure out your OAuth workflow, but it sounds like it might be unnecessary.
I'm looking for a way to create a api token after registration without session
And I also have a question:
Regular site have session to identify the current user
But in api How can I identify the current user if we do not create for him a session?
I'm having trouble with these questions
The main concept is that in login request you send e-mail and password and you get the token.
In all next request you send always this token (so you know which user makes the request) and for this you also send other data (if they are necessary).
Of course you need to make sure this token is somehow unique so you can now exactly which user is making the request.
You can implement it on your own or you can take advantage on some ready components.
In fact in Laravel 5.2 you have TokenGuard built in so you can create simple token authentication out of the box. You can watch this movie on Laracasts for further details.
You can also use some other packages for example JWT Auth