Related
So when using Facebook login, it turns out that if you set response_type to token or code%20token then the "response data is included as a URL fragment" on the URL that redirects to your app. Seriously, why? When would that ever be useful to anyone?
Anyway, I'm hoping that this is somehow security related and that it's there for a reason other than to annoy people, but I would otherwise like to know if there's a way to disable it, since I'm using Angular and it's a real pain to handle urls with hashbangs.
If I set a response_type of code only, the code is returned as a nice and clean query parameter, but I would like to receive both in order to perform additional validations. Is there a way to change this behaviour? Thanks.
EDIT:
Well it turns out that setting a response_type of code returns #/= at the end of the url, so there's no way to get a clean querystring. It has already been established that there is no way to change this behaviour, but I'm still interested in finding out why Facebook is doing it. Is it security related? What is the purpose of these url fragments?
Answers
To your first question, I imagine you would use token when you are handling everything in-browser and not processing at the server.
To your main question, as far as I know, you can not change how Facebook redirects successful authorizations. Facebook doesn't give you the token as a clean query parameter. If you use token or code token, what you want will be in the hash fragment. Sorry.
NOTE: This may not be a problem for you. I'm not sure what you want with "additional validations", but when you use code token, exchanging the resulting code gets you a different token than the one you just got embedded in the URI. Both are now valid and will expire separately. Really, you probably need either the code or the token; both won't help you since they're not linked.
Examples of using all three methods:
If you set response_type to code you get redirected to something like:
http://example.com/redirect_uri?state=thestatepassed&code=AQDN9E9GYjA8NbyCt
87_jV5vHnCQylNxmBswo6Z1BsrR7lmTPom6wjrzfan6P4GBLDt3EQrfPg0xSLoMLxBBfscsyfSY
JNM2vu9OoqEQXXSJCTUq_fMpUwqkYbCHp-GAqL4H1ymbMz7zPKAG61V9BtKTSuez39yhawOu7l-
6ww4thP41Ka9PVcknTQ6fPjPXKYSyxEmANps9zevCPFsXpBZCO7_dms65-ZZuG2wVBd16gFnBZH
q8EY0qih6-9o61wXh7bBvVPVSZ2im7Oj1nx47YgDpbD3X0XdlVhUoGYmBdER9hNmIC2PmmY7VAo
PlYCZc#_-_
From there, you need to exchange the code through Facebook's OAuth endpoint to receive an access token. The access token can then be used against the Facebook APIs.
If you set response_type to token you get redirected to something like:
http://example.com/redirect_uri#access_token=CAACYnSxGEhsBAJBg0ohZBhAf7pKEU
sm5ytZAZBzKjISFuRun2ZByZCqEsxrVIgtiO7iIlJZBBbGm6fRPQXItZCX6YgjPknUBsr78tJtv
W6fySULrUo9vdW57ZCMUUIlNaeZAcU8DzUXKmFpgotOyhE3jXYz1c3eu00Aii0AZBsPrtrwjpwQ
mV8VYQNiqKZBIsqOrIwZD&expires_in=4168&state=thestatepassed
You have everything you need to call the Facebook APIs. The access token returned is valid, but should probably be checked against Facebook's token inspection endpoint if you're doing something server-side. (Really, at that point, just use code. I've never done it this way, so good luck.)
As you noted, the access token is now contained within the hash fragment of the url.
If you set response_type to code token you get redirected to something like:
http://example.com/redirect_uri#code=AQAtzsjPivFPsJ538KFlPuhLaK6pDMlrGDiwmi
KDcpgNfWrO1EdX5i6zK_Op2D0QDEXZLyifXxh4TSeBZCWhnkl7YV1LMyEkbPURAWSoqRoeG7tfM
4nB4nDAHOK0H9umb0KnoypRT1pP05FJKhl2QjpCJrPPFDHl6y-1X9ZMj1uVHtmPNi4tG_6QAbuL
RaGadBkekb22uJ0iwSrWc9OKi6ET70lCTYb18hbwUkzHXtTq12nNEdsDJ7Ku2wEBwMygFwErYDX
CrnPoFoah_z0UPCfv3XZLy98Dhlzw_lnx8nnCB-PCppOWRqmydvQJehPd86k&access_token=C
AACYnSxGEhsBALXHRQwfm4UoauRlZBJDVpZCiM6ZCuM3bE965F5JVBfBB8inTFdhfJ5obnonSqa
m3v8FbWhHXrhRSx4ugwAmmDaWyxmPELWqSrkrDO5ueTUXhhjiEZBTd7HjCVCSOXXhOSo3DjEVSC
lOaZBfqmXsprYyc6LJC39sroCcHYCZCv&expires_in=5183426&state=thestatepassed
Now you have both an access token and a code (that expiration applies to the token, not the code). As stated earlier, that code can be exchanged for an access token in the usual way, but the returned access token will be different from the one you just got embedded in the URI.
But, again, what you care about is in the hash fragment.
See the AngularJS doc on $location for accessing the hash. Someone more knowledgable than me can speak to how that works with routes and how best to scrape the parameters.
Well today I had the same situation and managed to resolve it in a way I could get the access token from my server.
After getting the code using response_type=code I called via GET the following url:
https://graph.facebook.com/v3.2/oauth/access_token?app_id=MY_APP_ID&code=MY_CODE&client_id=MY_APP_ID&client_secret=MY_APP_SECRET&redirect_uri=YOUR_LOGIN_REDIRECT_URI
This route returns a JSON response, which has the access_token parameter, in this way:
{
"access_token": "ABAECAEFAEFAEA...",
"type": "bearer",
"expires_in": 838383838
}
So there you go :) I hope this works for you too
I'm using FB.login on the JS client and want to verify the user's identity on the server. So, the client gets a signedRequest from facebook and sends it to the server. The server splits on the period, and decodes the second part of the signedRequest into a json object.
What should I be using for "code" when I send my server-side request to
https://graph.facebook.com/oauth/access_token?
client_id=YOUR_APP_ID
&redirect_uri=YOUR_REDIRECT_URI
&client_secret=YOUR_APP_SECRET
&code=CODE_GENERATED_BY_FACEBOOK
My decoded json looks something like:
{"algorithm":"HMAC-SHA256","code":"2.AQCPA_yfx4JHpufjP.3600.1335646800.1-5702286|l11asGeDQTMo3MrMx3SC0PksALj6g","issued_at":1335642445,"user_id":"5232286"}
Is that the code I need? Does it need to be B64 encoded? If this isn't the code, what code should I use?
_
What I've tried:
The request I'm trying to use is:
https://graph.facebook.com/oauth/access_token?client_id=295410083869479&redirect_uri=https://squaredme.appspot.com/facebookredirect&client_secret=44f1TOPSECRETbb8e&code=2.AQCPA_yfx4JHpufjP.3600.1335646800.1-5702286|l11asGeDQTMo3MrMx3SC0PksALj6g
but this returns the error:
{"error":{"message":"Error validating verification code.","type":"OAuthException","code":100}}
I can't tell if this is because I'm using a bad code, or what. Noteably, this is running on my local dev server, and squaredme.appspot.com definitely does NOT resolve to my IP. I don't know if facebook checks that or what - I'm assuming I'd get a better error message. Thanks for any direction!
You are trying to somehow combine the two flows together and that's why things don't work well.
When facebook POSTs into the iframe with your app url and a signed request there are two options, the easy one being that the user is already authenticated and then the signed request will have all the necessary data (including a signed request), then you just load the canvas page and use the JS SDK to get an access token there as well, but in this case there's no need to use the FB.login (since it opens a popup and will automatically close it), you can use the FB.getLoginStatus method which won't annoy the user.
If the user is not authenticated then the sign request will be missing the things you need to use the graph api.
You then redirect the user to the auth dialog, and since you are loaded in an iframe you'll need to return a html response which redirects the parent window using javascript, like:
top.location.href = "AUTH_DIALOG_URL";
When the use is done (accepted or rejected the app) he will be redirected to the "redirect_uri" you added as a parameter to the auth dialog.
If the user accepted your app then you'll be getting the "code" parameter in the query string.
You then take the code, exchange it with an access token as you posted in your question, and then redirect the user back to "apps.facebook.com/YOUR_APP".
When the page then loads the user is already authenticated and you'll be getting a full signed request.
I hope this clarifies things for you, recheck the Server-Side flow it pretty much covers it all.
I also had some trouble with that, then I found the solution here in StackOverflow.
There are two kinds of "code" provided by facebook. One comes inside the signedRequest in the cookie generated by the client-side flow. The Facebook's JS SDK handles this codes and get a access token without telling us anything.
The other type of code comes attached as a query to your redirect URI (http://www.yoururl.com/index.php?code=AAAgyiaus...), when you navigate to OAuth URL (server-side flow). With this code, you go to a Token URL and get your access token.
When you are using the server-side flow, you need to indicate a redirect URI both in the OAuth URL AND in the Token URL, and they have to be exactly the same, so a missing slash or a query string can be a lot of problem.
The codes are different from each other. When you use the both things together, appears to be impossible to get a access token using the code that was inside the cookie's signedRequest.
BUT, it is not. The magic is: the code from signedRequest is associated with NO URI, so as long as the redirect_uri is a mandatory field, all you have to do is to pass it blank when you navigate to the Token URL.
So the final solution is: grab the signedRequest from the cookie, parse it in your server to obtain the code, then read the Token URL:
https://graph.facebook.com/oauth/access_token?
client_id=YOUR_APP_ID
&redirect_uri=&client_secret=YOUR_APP_SECRET
&code=CODE_INSIDE_THE_SIGNED_REQUEST
It looks like a hack, so I don't know how long it's gonna work, but it's working right now.
There seems to be a lot of confusion about the correct http status code to return if the user tries to access a page which requires the user to login.
So basically what status code will be send when I show the login page?
I'm pretty sure we need to use a status code in the 4xx range.
I'm not talking about HTTP authentication here, so that's at least 1 status code we aren't going to use (401 Unauthorized).
Now what should we use? The answers (also here on SO) seem to vary:
According to the answer here we should use 403 Forbidden.
But in the description of the status code is:
Authorization will not help and the request SHOULD NOT be repeated.
Well that doesn't look like the right one. Since authorization WOULD help.
So let´s check out some other answer. The answer here even doesn't use the 4xx range at all but rather uses 302 Found
The description of the 302 Found status code:
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
I think that also isn't what I want. Since it is not the requested resource which resides under a different URI. But rather a completely different resource (login page vs authenticated content page).
So I moved along and picked another answer surprisingly with yet another solution.
This answer suggest we choose 400 Bad Request.
The description of this status code is:
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
I think the server understood the request just fine, but just refuses to give access before the user is authenticated.
Another answer also says a 403 response is correct, however it ends with:
If this is a public facing website where you are trying to deny access based on a session cookie [that's what I do], 200 with an appropriate body to indicate that log in is needed or a 302 temporary redirect to a log in page is often best.
So 403 is correct, but 200 or 302 is THE BEST.
Hey! That's what I am looking for: THE BEST solution. But shouldn't the best be the same as the correct one? And why would it be the best?
Thanks to all who have made it this far into this question :)
I know I shouldn't worry too much about it. And I think this question is more hypothetical (not really, but used it because of lack of a better word).
But this question is haunting me for some time now.
And if I would have been a manager (who just picked up some cool sounding words as they always do) I would have said: but, but, but, but restfulness is important. :-)
So: what is the right way™ of using a status code in the above situation (if any)?
tl;dr
What is the correct http status code response when a user tries to access a page which requires login?
If the user has not provided any credentials and your API requires them, return a 401 - Unauthorized. That will challenge the client to do so. There's usually little debate about this particular scenario.
If the user has provided valid credentials but they are insufficient to access the requested resource (perhaps the credentials were for a freemium account but the requested resource is only for your paid users), you have a couple of options given the looseness of some of the HTTP code definitions:
Return 403 - Forbidden. This is more descriptive and is typically understood as, "the supplied credentials were valid but still were not enough to grant access"
Return 401 - Unauthorized. If you're paranoid about security, you might not want to give the extra information back to the client as was returned in (1) above
Return either 401 or 403 but with helpful information in the response body describing the reasons why access is being denied. Again, that information might be more than you would want to provide in case it helps attackers somewhat.
Personally, I've always used #1 for the scenario where valid credentials have been passed but the account they're associated with doesn't have access to the requested resource.
You ask for "the best", "the right way", and "the correct", in turn, which makes answering this question difficult because those criteria are not necessarily interchangeable and may, in fact, conflict -- especially where RESTfulness is concerned.
The "best" answer depends on your application. Are you building a Plain Old Browser-Based (POBB) web-application? Are you building a native client (ex. iOS or Android) and hitting a service over the Web? Are you making heavy use of AJAX to drive web-page updates? Is curl the intended client?
Let's assume you are building a traditional web application. Let's look at how Google does it (output chopped for brevity):
$ curl -v http://gmail.com/
< HTTP/1.1 301 Moved Permanently
< Location: http://mail.google.com/mail/
< Content-Type: text/html; charset=UTF-8
< Content-Length: 225
< ...
Google first redirects us to the "true" URL for GMail (using a 302 redirect).
$ curl -v http://mail.google.com/mail/
< HTTP/1.1 302 Moved Temporarily
< Location: https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=http://mail.google.com/mail/&scc=1<mpl=default<mplcache=2
< Content-Type: text/html; charset=UTF-8
< Content-Length: 352
< ...
And then it redirects us to the login page (using a 302 redirect).
$ curl -v 'https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=http://mail.google.com/mail/&scc=1<mpl=default<mplcache=2'
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< ...
The login page itself is delivered with the 200 status code!
Why this way?
From a user-experience perspective, if a user goes to a page they can't view because they are not authenticated, you want to take the user to a page that allows them to correct this (via logging in). In this example, the login page stands alone and is just another page (which is why 200 is appropriate).
You could throw up a 4XX page with an explanation and a link to the login page. That might, in fact, seem more RESTful. But it's a worse user experience.
Ok, but is there a case where something like 403 makes sense? Absolutely.
First, though, note that 403 isn't well-defined in the specification. In order to understand how it should be used, you need to look at how it's implemented in the field.
403 is commonly used by web servers like Apache and IIS as the status code for pages returned when the browser requests a directory listing (a URI ending in "/") but the server has directory listings disabled. In this case, 403 is really a specialized 404, and there isn't much you can do for the user except let him/her know what went wrong.
However, here's an example of a site that uses the 403 to both signal to the user that he/she doesn't have sufficient privilege and what action to take to correct the situation (check out the full response for details):
curl -v http://www.w3.org/Protocols/rfc2616/
< HTTP/1.1 403 Forbidden
< Content-Type: text/html; charset=iso-8859-1
< Content-Length: 1564
< ...
(As an aside, 403 is also seen in web-based APIs, like Twitter's API; here, 403 means "The request is understood, but it has been refused. An accompanying error message will explain why. This code is used when requests are being denied due to update limits.")
As an improvement, let's assume, however, that you don't want to redirect the user to a login page, or force the user to follow a link to the login page. Instead, you want to display the login form on the page that the user is prevented from seeing. If they successfully authenticate, they see the content when the page reloads; if they fail, they get the login form again. They never navigate to another URL.
In this case, a status code of 403 makes a lot of sense, and is homologous to the 401 case, with the caveat that the browser won't pop up a dialog asking the user to authenticate -- the form is in the page itself.
This approach to authentication is not common, but it could make sense, and is IMHO preferable to the pop-up-a-javascript-modal-to-log-in solutions that developers try to implement.
It comes down to the question, do you want to redirect or not?
Additional: thoughts about the 401 status code...
The 401 status code -- and associated basic/digest authentication -- has many things going for it. It's embraced by the HTTP specification, it's supported by every major browser, it's not inherently un-RESTful... The problem is, from a user experience perspective, it's very very unattractive. There's the un-stylable, cryptic pop-up dialog, lack of an elegant solution for logging out, etc. If you (or your stakeholders/clients) can live with those issues (a big if) then it might qualify as the "correct" solution.
Agreed. REST is just a style, not a strict protocol. Many public web services deviate from this style. You can build your service to return whatever you want. Just make sure your clients know how what return codes to expect.
Personally, I have always used 401 (unauthorized) to indicate an unauthenticated user has requested a resource that requires a login. I then require the client application to guide the user to the login.
I use 400 (bad request) in response to a logon attempt with invalid credentials.
HTTP 302 (moved) seems more appropriate for web applications where the client is a browser. Browsers typically follow the re-direct address in the response. This can be useful for guiding the user to a logon page.
I'm not talking about HTTP authentication here, so that's at least 1 status code we aren't going to use (401 Unauthorized).
Wrong. 401 is part of Hypertext Transfer Protocol (RFC 2616 Fielding, et al.), but not limited to HTTP authentication. Furthermore, it's the only status code indicating that the request requires user authentication.
302 & 200 codes could be used and is easier to implement in some scenarios, but not all. And if you want to obey the specs, 401 is the only correct answer there is.
And 403 is indeed the most wrong code to return. As you correctly stated...
Authorization will not help and the request SHOULD NOT be repeated.
So this is clearly not suitable to indicate that authorization is an option.
I would stick to the standard: 401 Unauthorized
-
UPDATE
To add a little more info, lifting the confusion related to...
The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource.
If you think that's going to stop you from using a 401, you have to remember there's more:
"The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI."
This "indicating the authentication scheme(s)" means you can opt-in for other auth-schemes!
The HTTP protocol (RFC 2616) defines a simple framework for access authentication schemes, but you don't HAVE to use THAT framework.
In other words: you're not bound to the usual WWW-Auth. You only just MUST indicate HOW your webapp does it's authorization and offer the according data in the header, that's all. According to the specs, using a 401, you can choose your own poison of authorization! And that's where your "webapp" can do what YOU want it to do when it comes to the 401 header and your authorization implementation.
Don't let the specs confuse you, thinking you HAVE to use the usual HTTP authentication scheme. You don't! The only thing the specs really enforce: you just HAVE/MUST identify your webapp's authentication scheme and pass on related parameters to enable the requesting party to start potential authorization attempts.
And if you're still unsure, I can put all this into a simple but understandable perspective: let's say you're going to invent a new authorization scheme tomorrow, then the specs allow you to use that too. If the specs would have restricted implementation of such newer authorization technology implementations, those specs would've been modified ages ago. The specs define standards, but they do not really limit the multitude of potential implementations.
Your "TL;DR" doesn't match the "TL" version.
The proper response for requesting a resource that you need authorization to request, is 401.
302 is not the proper response, because, in fact, the resource is not available some place else. The original URL was correct, the client simply didn't have the rights. If you follow the redirect, you do not actually get what you're looking for. You get dropped in to some ad hoc workflow that has nothing to do with the resource.
403 is incorrect. 403 is the "can't get there from here" error. You simply can't see this, I don't care who you are. Some would argue 403 and 404 are similar. The difference is simply with 403, the server is saying "yea, I have it, but you can't", whereas 404 says "I know nothing about what you're talking about." Security wonks would argue that 404 is "safer". Why tell them something they don't need to know.
The problem you are encountering has nothing to do with REST or HTTP. Your problem is trying to set up some stateful relationship between the client and server, manifested in the end via some cookie. The whole resource -> 302 -> Login page is all about user experience using the hack that's known as the Web Browser, which happens to be both, in stock form, a lousy HTTP client and a lousy REST participant.
HTTP has an authorization mechanism. The Authorization header. The user experience around it, in a generic browser, is awful. So no one uses it.
So there is not proper HTTP response (well there is, 401, but don't/can't use that). There is not proper REST response, as REST typically relies on the underlying protocol (HTTP in this case, but we've tackled that already).
So. 302 -> 200 for the login page is all she wrote. That's what you get. If you weren't using the browser, or did everything via XHR or some other custom client, this wouldn't be an issue. You'd just use Authorization header, follow the HTTP protocol, and leverage a scheme like either DIGEST or what AWS uses, and be done. Then you can use the appropriate standards to answer questions like these.
As you point out, 403 Forbidden is explicitly defined with the phrase "Authorization will not help", but it is worth noting that the authors were almost certainly referring here to HTTP authorization (which will indeed not help as your site uses a different authorization scheme). Indeed, given that the status code is a signal to the user agent rather than the user, such a code would be correct insofar as any authorization the agent attempts to provide will not assist any further with the required authorization process (c.f. 401 Unauthorized).
However, if you take that definition of 403 Forbidden literally and feel it is still inappropriate, perhaps 409 Conflict might apply? As defined in RFC 2616 §10.4.10:
The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict
and resubmit the request. The response body SHOULD include enough
information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem; however, that might not be
possible and is not required.
There is indeed a conflict with the current state of the resource: the resource is in a "locked" state and such conflict can only be "resolved" through the user providing their credentials and resubmitting the request. The body will include "enough information for the user to recognize the source of the conflict" (it will state that they are not logged-in) and indeed will also include "enough information for the user or user agent to fix the problem" (i.e. a login form).
Your Answer:
401 Unauthorized especially if you do not care or will not be redirecting people to a login page
-or-
302 Found to imply there was the resource but they need to provide credentials to be returned to it. Do this only if you will be using a redirect and make sure to provide appropriate information in the body of the response.
Other Suggestions:
401 Unauthorized is generally used for resources the user does not have access to after handling authentication.
403 Forbidden is a little obscure to me in honesty. I use it when I lock down resources from the file system level, and like your post said, "authorization does not help".
400 Bad Request is inappropriate as needing to login does not represent malformed syntax.
I believe 401 is the correct status code to return from failed authorization. Reference RFC 2616 section-14.8
It reads "A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response"
I'm designing a public API to my company's data. We want application developers to sign up for an API key so that we can monitor use and overuse.
Since the API is REST, my initial thought is to put this key in a custom header. This is how I've seen Google, Amazon, and Yahoo do it. My boss, on the other hand, thinks the API is easier to use if the key becomes merely a part of the URL, etc. "http://api.domain.tld/longapikey1234/resource". I guess there is something to be said for that, but it violates the principle of the URL as a simple address of what you want, and not how or why you want it.
Would you find it logical to put the key in the URL? Or would you rather not have to manually set HTTP headers if writing a simple javascript frontend to some data?
It should be put in the HTTP Authorization header. The spec is here https://www.rfc-editor.org/rfc/rfc7235
If you want an argument that might appeal to a boss: Think about what a URL is. URLs are public. People copy and paste them. They share them, they put them on advertisements. Nothing prevents someone (knowingly or not) from mailing that URL around for other people to use. If your API key is in that URL, everybody has it.
It is better to use API Key in header, not in URL.
URLs are saved in browser's history if it is tried from browser. It is very rare scenario. But problem comes when the backend server logs all URLs. It might expose the API key.
In two ways, you can use API Key in header
Basic Authorization:
Example from stripe:
curl https://api.stripe.com/v1/charges -u sk_test_BQokikJOvBiI2HlWgH4olfQ2:
curl uses the -u flag to pass basic auth credentials (adding a colon after your API key will prevent it from asking you for a password).
Custom Header
curl -H "X-API-KEY: 6fa741de1bdd1d91830ba" https://api.mydomain.com/v1/users
passing api key in parameters makes it difficult for clients to keep their APIkeys secret, they tend to leak keys on a regular basis.
A better approach is to pass it in header of request url.you can set user-key header in your code .
For testing your request Url you can use Postman app in google chrome by setting user-key header to your api-key.
I would not put the key in the url, as it does violate this loose 'standard' that is REST. However, if you did, I would place it in the 'user' portion of the url.
eg: http://me#example.com/myresource/myid
This way it can also be passed as headers with basic-auth.
Im trying to get TripIt OAuth authentication working, but I find the documentation to go a bit over my head. TripIt docs
The paragraph below is from the documentation, I have tried putting together a POST request for a SOAP service where the documentation specified what to put into the headers and how to build an xml for the Http body. In this case I have no idea on how to build my request.
I have all the values the service asks for, just no idea of how to set these using only the info given below?
To obtain an authorized access token,
POST the following request parameters
to the URL:
https://api.tripit.com/oauth/access_token
oauth_consumer_key: The Consumer's public key.
oauth_nonce: A nonce no more than 80 characters in length.
oauth_signature: The signature of the reque…
oauth_signature_method: Current supported methods are HMAC-SHA1.
oauth_timestamp: The timestamp in seconds since the epoch.
oauth_token: The request token obtained in Step 1.
oauth_token_secret: The request token secret obtained in Step 1.
oauth_version: OPTIONAL - Assumed to be '1.0'
Could someone help me with how I'll go about building the POST request from the above?
Thank you:)
The way to do it yourself would be to read up on how the body of a POST request is put together (it looks a lot like a URL query string), build the string out of the various parts, and then use the request's -setHTTPBody: method.
Most people recommend using ASIHTTPRequest, which, among many other things, will do that work for you. See, in particular, the ASIFormDataRequest class, and its -setPostValue:forKey: method.
Here's some more detail on the format of the POST body:
From the W3C HTML4 spec, the section on forms.
The Wikipedia entry on "percent escaping".
From the HTML5 spec draft. These rules should be backwards-compatible, while being more precise than the text in the HTML4 spec, but no promises.