For my testing purposes, I've checked every box in the scope of the app setup, including offline access. But that gives me an error saying that "API permission failed". (it's also used as a Bearer token in the authorization header). In that case, the authorization code has already been exchanged for an access key, so it's no longer valid.Īssuming that's the case, I've tried using the Access Key in the header of a SOAP request. This is my first time ever using an OAuth2.0 workflow, so I'm not sure, but it occurs to me that the reason the codes are different and my token request is failing is that Postman has already made the token request using the authorization code provided to the callback URL. Both result in an "invalid authorization code" error. In the next screenshot, I use the value appended to the callback URL as the "code" parameter in my request, but I've also tried using the access code that was retrieved by Postman. Once I get the authorization code, I try to make a call to the v2/token endpoint to obtain an access key, following this documentation. Why are these values different? Where is Postman even getting this different access key information if not from the code appended to the callback URL? Last few characters of the Access Token retrieved by Postman: Last few characters of the code appended to the callback URL: If I compare the Access Token that's been received by Postman to the "code" parameter returned in the callback URL, they are not the same. When I go back to Postman, it presents me with information about the token I've just received. My browser redirects to the Callback URL for postman and tells me my call is authenticated. Then I'm taken out to my browser, where I log in to Salesforce. Postman provides this awesome feature of performing any scripts before actually sending the actual configured request.īy setting up an easy request to check if my currently stored access token from the environment variables is still valid, I'm able to handle the resetting of it completely behind the scenes.įirst of all, I'm making a basic request to check if my access token stored in the environment variable is still valid by accessing a route which definitly needs authentication.I have created a web app component in Salesforce Marketing Cloud, and now I'm trying to get the OAuth2.0 flow to work in Postman.įirst, I use the Authorization tab in Postman to request a token. Until I got behind the use of pre-request scripts for this kind of tasks. Something a developer should not be afraid of in my opinion. This might not sound like much, but it can be annoying and is something that holds me back from resetting and reseeding my database. While doing this, my access token gets invalid so I need to go back to my login route, make a login request, copy the returned access token and store it in my environment variables. So you only have to change a single, central variable for all requests that are configured to use the environment variable as its Bearer Token.īut as matter of fact, within the current stage of development I am in need to reset my database multiple times a day and it gets seeded with fresh data each time. provide the access token once for a collection of requests. That's where environment variables might come into play as a very handy tool. Of course every API developing client provides an easy way to set the required headers easily, so does Postman:īut as a project grows, the amount of preconfigured requests grows. The authentication system itself is using a bearer token. It's build with Laravel, which doesn't really matter within this context, as this post about the API and Postman.Ī key characteristic of this API is most endpoints are only accessible for authenticated users, which I guess, is a common thing. This is something I recently discovered and found very useful in my daily work so I think it's worth sharing.Ĭurrently I'm locally developing an JSON API.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |