I am trying to get tweets from a user with his screen name, but I am getting code 32 401 unauthorized error, i tried encoding the details it's not working, Please let me know what is the issue here
Below is the get request I am sending via postman, I have attached photo for more understanding
GET /1.1/statuses/user_timeline.json?screen_name=urstrulyMahesh HTTP/1.1
Host: api.twitter.com
Authorization: OAuth oauth_consumer_key="hwWrdsCbnYA6duRPn9b5eOL2b",oauth_token="920656878140645376-spRRFqnUdYyRKXJdP2Bd1SuN1TeJP8B",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1508349347",oauth_nonce="JKLMNOPQRSTUVWXYZABC123DEFGHI494",oauth_version="1.0",oauth_signature="A0mdEkSUjwWOO8AfX0S4oU296Q4%253D"
Cache-Control: no-cache
Postman-Token: b5bfb83b-e2c6-0e23-81b0-38daee989fec
I am sure access tokens and customer tokens are entered correctly
Please point out the error
That won't work because your Authorization header doesn't follow the OAuth protocol. All of your credentials are in plain text, but the value must pass through several steps of encoding and encryption before they can be sent to Twitter. You'll have to do this with code because part of the protocol includes a timestamp, which is likely to expire before you can do it by hand. Here's the process, on Twitter's site:
Authorizing a Request
There are several 3rd party Twitter Libraries that do this in several programming languages. One of the things you might be able to do is write the code with the same parameters you're using for Postman, set a breakpoint, and copy the Authorization header when the code hits the breakpoint.
Note: You've posted code and a picture with your application secrets.
That means that anyone who wants to can use your secrets to interact
with Twitter on your behalf. To protect yourself, you should either
re-key or delete the Twitter application (if it was just for test) and
create a new one with new secrets.
Related
I am building an oauth login flow and I am not sure if I have done it wrong because I will need to send the bearer token back via redirect URL, like /oauth2/redirect?token=[TOKEN]. But isn't it not recommended to have token passed along through URL? As it is pointed out in this thread:
Don't pass bearer tokens in page URLs: Bearer tokens SHOULD NOT be passed in page URLs (for example, as query string parameters).Instead, bearer tokens SHOULD be passed in HTTP message headers or message bodies for which confidentiality measures are taken. Browsers, web servers, and other software may not adequately secure URLs in the browser history, web server logs, and other data structures. If bearer tokens are passed in page URLs, attackers might be able to steal them from the history data, logs, or other unsecured locations.
I must have missed something in the whole flow and would like to understand more about this matter. Any input is appreciated!
UPDATE
Might not be correct but this is my understanding after some digging. The three means to pass token:
URL (not preferable)
Auth header
Request body
But under the oauth redirect use case, option 2 and 3 not feasible. So option 1 is the only option available. If really needed, token can be encrypted to ensure security.
I think this only means, that you should not use a GET request when the server requires the token, instead you should use POST or whatever is appropriate. In a GET request the parameters are included in the URL and those can end up in logs or other histories, other request types will send the paramters separat from the request URL.
P.S. BTW if you are not implementing the OAuth server yourself, you won't have to send a redirect url containing the token.
The basic auth header which provides a little extra security as it's required to be through TLS:
In the case of a "Basic" authentication like shown in the figure, the exchange must happen over an HTTPS (TLS) connection to be secure.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication
Also, the headers aren't logged in easy places like browser history.
From the spec,
it SHOULD NOT be used
unless it is impossible to transport the access token in the
"Authorization" request header field or the HTTP request entity-body.
https://www.rfc-editor.org/rfc/rfc6750#section-2.3
Summary
Cannot get headers [“Set-Cookie”] when login into the system with custom login
Steps to reproduce
Use Postman, try to login to workspace with your credentials, view headers. You will not see the “Set-Cookie”
Expected behavior
Request headers should have the “Set-Cookie” headers.
Observed behavior
Request headers does not have the “Set-Cookie” headers.
Extra info for context
Im currently developing a custom app for our company using mattermost as the backbone. I created the login and moved on to design the rest of the app, when I went to start making api request all of them would fail. After checking the web client to verify why they were failing, I saw the login had the “set-cookie” headers and they would be used in every request. There I understood my problem.
I needed the set-cookies for every request, so I went and checked the request headers in the app response headers and saw that they were not there. After that I tried with a custom backend that would do the request, same not there. After that I went to postman and same. Without the data in the set-cookies I can’t continue.
Any help would be appreciated,
I understand that OAuth2 is a good way to secure access to a REST API. I also understand that unlike in a simple website or in a SOAP API, in a REST API you want to use the right HTTP method for the right task. That is GET to read data, POST to write, etc.
My question is, when doing a GET call to a REST API secured via OAuth2, how do you protect your access token ? I don't see any other way to pass it to the server than in clear view in the URL, so isn't it that anybody that can see my call on the network could hijack my authorization ?
A HTTP request has a couple of major components:
The method
The url
Headers
Body
The OAuth2 Bearer token is usually sent in the headers, as such:
GET /thingy HTTP/1.1
Host: api.example.org
Authorization: Bearer [secret]
As an aside, this assumption is not really correct either:
so isn't it that anybody that can see my call on the network could hijack my authorization ?
If you don't use HTTPS, anyone can still see this token even if it's in a header. If you do use HTTPS, putting a token in the url shouldn't allow anyone else to snoop. However, putting secrets in urls is considered a bad practice for different reasons. Specifically, people don't like it because the tokens can end up in a browsers history and in logs. This increases the chances of it accidentally falling in the wrong hands.
I maybe missing an important piece of jwt concept but I'm having a hard time finding info on where the server is supposed to include the generated json web token in the response and where the client is supposed to include it in the subsequent requests. Are there any rules/guidelines/best practices on that?
The JWT should be sent to the client in the response body. In the subsequent requests you've got to include an header field called Authorization with the token.
Check this link for more details.
There seems to be 2 HTTP Authentication: Basic access authentication and Digest access authentication
So I think in general, a user tries to access a URL, and the web server returns 401 Unauthorized, and then the browser
pops up an app window, asking for username and password, and then set the credentials in the HTTP headers then sends the HTTP request again.
What about http://peter:mypassword#www.somesite.com ? Is that supposed to not wait for the 401 to come back but provide the username and password in advance?
Some how, I tried http://peter:mypassword#www.google.com or yahoo but inside of Fiddler (to monitor net traffic), I don't see any credential info in the HTTP request?
You still need to send the 401 on the server side. The user:pass#host is just a convenience to avoid displaying the login dialog.
If you think about it, this makes sense, because if you don't send the 401 with the header explaining which method to use, the client doesn't know how to format the credentials.
(There are actually any number of schemes, not just Basic and Digest.)
For some understanding of it, there is a Railscast that talks about HTTP Basic Authentication and adding it to a Rails project and how it looks like on a browser: http://railscasts.com/episodes/82-http-basic-authentication