I have a question about REST. I´m creating a service, in which the client sends HTTP request with Basic authorization (Header Authorization: Basic user:password). I want the server to control user credentials, and if they are correct, it would send 200 OK, otherwise 401 Unauthorized. If the credentials are OK, I want to send back also user´s ID. My question is, what would be the best way to send that? My options are: headers, or json in the body of the response. Thanks you in advance.
Personally, I would send it back in the body. I don't think there are any standard headers suitable for that type of information, unless you are setting it in a cookie.
Related
i have a fairly simple testplan with following steps recorded
Thread Group
Recording Controller
HTTP Authorization manager
GET https://xxxx/user/login
GET https://xxxx/accounts/list
GET https://xxxx/user/settings
GET https://xxxx/partners/list
GET https://xxxx/user/logout
When i run this, i see jmeter adding the authorization header in the first user/login request and server responds with 200 OK. This is OK
i extract the session token from the login response and put it as a variable into the subsequent http requests.
jmeter is not adding the authorization header in the subsequent accounts/list request - this is OK
but then jmeter is adding the authorization header into the subsequent user/settings request - this is not needed as it defeats the purpose of sending the session token.
Again jmeter is not sending the auth token in partners/list but is sending it again in user/logout request.
So question is how jmeter determines when to add the auth header and when not?
The desired behaviour i want is for jmeter to send the auth header in the first user/login request but not in any of the subsequent http requests.
Any pointers appreciated.
thanks
HTTP Authorization Manager will add Authorization header to all the HTTP Request samplers it its scope, if you place it at the same level with the HTTP Request samplers - it will add the header to all of them.
If you need to apply the HTTP Authorization Manager to 1st sampler only - move it to be the child of the first sampler.
More information: JMeter Scoping Rules - The Ultimate Guide
Recording any scenario adds up the Header Manager in all the Http requests.
You are doing it in correct way, however still you have to make few changes in your scripts to run seamlessly.
Delete all the subsequent Header Manager under the accounts/list,user/settings,partners/list & logout.
Post the Login Request > extract the session > Add a Header Manager after Login request and pass the session there.
All the further request should be in the same thread so that the session get passed to each request.
Also while recording there are multiple requests that gets captured and for each scenario Jmeter maintains the session under Header Manager, hence this should never be the case that one request is getting the session while others not.
Thanks for the answer that helps.
What i did and worked well in the mean time is add an explicit authorization header to the user/login request with a beanshell preprocessor to base64 encode the username / password.
thanks anyways
I'm trying to determine what a client should do with headers on receiving a 303 (See Other) from the server. Specifically, what should be done with the Authorization header that was sent on the initial request?
Here's the problem: the client makes a request to myserver.com (HTTP request method is not relevant here) and the server at myserver.com responds with a 303 and the Location header contains otherserver.com/some_resource/. Tools like Postman and curl will follow the redirect by passing all the same headers in the subsequent request to otherserver.com. I haven't found a way to make these tools drop the headers.
In the case I've described, sending the Authorization header to otherserver.com seems like a security risk: otherserver.com now knows my token and possibly what host it can be used on so now the token is compromised. This can also cause errors, depending on how the destination host is configured. In the case where the redirect is to another resources on the same host (ie, myserver.com) then the Authorization header will (probably) need to be sent, and because it's the same host nothing is compromised.
Effectively, in different situations it seems that the correct behaviour is different. The relevant section in the RFC does not address this issue. In developing my own API, I've written documentation telling API clients to drop the Authorization header on redirect to otherserver.com. However, based on mucking around with curl and Postman, it's not clear to me either (a) what the default behaviour is for a typical HTTP client library or (b) whether HTTP client libraries permit easy modification of the HTTP headers before following a 303 redirect. As a result, it's possible my suggestion isn't practical. I also know of no way for the server to instruct the client as to what it should do with headers on following the 303 redirect.
What should a HTTP client do with the headers when it follows a 303 redirect? Who is responsible for deciding whether to use the same headers on the redirect, the HTTP client or server?
You can argue that when sending the 303 with otherserver.com's Location, myserver.com trusted otherserver.com to handle your token. It could have sent the token in the background as well. From the client's perspective, the client trusts myserver.com to handle the token, store and verify it securely, etc. If myserver.com decides to send it on to otherserver.com, should the client override? In this case it can of course, but in general I don't think it should.
As an attacker does not control the response headers from myserver.com which is a legit resource, I think in general it is secure to send the token by default to the other server it specifies, maybe unless you have some good reason not to (say an explicit policy on the client).
Seems like http.get is forbidden since I don't send the cookie value with the request. If I just surf to the link I will get the response, since the browser send the cookie. How I do the same in typescrip code with angular 2?
Looking at this link:
https://angular.io/docs/ts/latest/api/http/index/RequestOptions-class.html
You can specify RequestOptions (such as header values) with your get request. I presume you could use that to send the cookie in the way you need. There's not much else for information in your question, so I think that's as close as I can get.
Http spec:
https://angular.io/docs/ts/latest/api/http/index/Http-class.html
I'm creating a RESTful service to provide data to a web application. I have two related questions about this.
1. How to deal with unauthorized requests?
I'm intending to respond to requests with the following codes:
Is the resource open and found? 200 OK
Do you need to be authenticated to access the resources? 401 Unauthorized
Don't you have access to a category of resources? 403 Forbidden
Do you have access to a category of resources, but not to this specific resource? 404 Not Found to prevent people from getting to know the existance of a resource they do not have access to.
Doesn't the resource exist? 404 Not Found
Is this a recommended way for a RESTful service to behave?
2. What WWW-Authenticate header should 401 responses supply?
I read on Wikipedia (probably not the most accurate resource, but it works for me) that a 401 response must include a WWW-Authenticate header, however upon further searching I couldn't really find any resource that stated what this value means and what it should be.
I found several SO questions and forum topics about this header and they all seem to be about OAuth, suggest against using 401 status codes or say you can just make something up.
What is the correct value this header should contain?
To answer your questions:
How to deal with unauthorized requests?
The way you described it is pretty much the recommended way for a RESTful service. As far as I can see there is absolutely nothing wrong with that.
What WWW-Authenticate header should 401 responses supply?
In general the WWW-Authenticate header tells the client what kind of authentication the server will accept. If the client makes an unauthorized request, which means he is sending a request with a missing or invalid Authorization header, the server will use WWW-Authenticate to tell the client what authentication scheme he will accept (i.e. Basic, Digest or OAuth) and for what realm.
Imagine it like some kind of identification question or challenge on the part of the server, i.e. something like "Who are you?" or "Prove who you are by providing credentials in the following way!".
For Example: WWW-Authenticate: Basic realm="My App"
Here the server tells the client that he uses an authentication scheme named Basic. The realm is nothing more than some string that identifies a protected space on the server.
Based on my research (googling) i decided to send: Newauth realm="use login token".
The website http://greenbytes.de/tech/tc/httpauth/#unknown has test cases for different auth methods and i haven't found anything which describes 'get auth token' and therefore i think it is a 'Newauth'.
Also important for me: This doesn't create a login prompt on client side.
In how many ways can an HTTP request be generated?
There are endless ways how you can create and from where you can send HTTP requests to a server. Actually your server has no idea, what the origin of such a request is (if it's AJAX or "regular" request, or sent from a console application or ...)
But there are HTTP methods (HTTP verbs) that (can) tell the server about the intent of the request: http://en.wikipedia.org/wiki/HTTP_Verbs#Request_methods
Also you can set headers in a request, for example the content-type or the accepted encoding: http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
Most JavaScript libraries for example set the (non-standard) HTTP header X-Requested-With, so your application can differentiate between regular and ajax requests.
You see, it's even possible to set your own, non-standard headers. There are endless possible combinations...
HttpRequest is a C# class that wraps a petition sent by a client during a Web request.
There are many ways to generate it. The most usual one happens when your browser connects to an ASP.NET website.
You can, for example, create your own custom HttpRequest to petition a specific web page from a C# console application.
Are you trying to achieve something more specific?