I have:
Request request = new Request(Method.GET, "https://www.awebsite.com/login");
Client client = new Client(Protocol.HTTPS);
Response response = client.handle(request);
...
response.getEntity().write(System.out);
But I don't know how to set the login parameters...
I want code that
does the escaping etc
can switch between get/post easily
Being a REST-based platform, I'm thinking I might need to use some parameter "representation" but that seems a bit strange. I'd think it would be common enough to build in this representational exception.
If by "login parameters" you mean sending credentials using Basic HTTP Authentication, it's done using Request.setChallengeResponse() like so:
Request request = new Request(Method.GET, "https://www.awebsite.com/login");
request.setChallengeResponse(new ChallengeResponse(ChallengeScheme.HTTP_BASIC, username, password));
This will work for any Request, using any HTTP method.
If, however, the server to which you're trying to authenticate expects credentials using some protocol other than Basic HTTP Auth, then you'll need to explain that protocol -- i.e. does it use cookies, headers, tokens, etc.
BTW, you might get faster/better responses by posting to the Restlet-Discuss mailing list; I've been on there for a year and a half and it's a great community.
Related
As a preface I'd like to claim I have some understanding of how the HTTP-supported authentication is supposed to work according to RFC 7235.
I am specifically interested to know how a client is supposed to know, after authenticating, which URIs on the server it is expected to provide same authorization (through the Authorization header) bearer for? Furthermore, is there any provision by HTTP to assist client in determining which Authorization headers it (the client) may have available (through whatever means it acquires them -- "login" form/dialog etc), would go with which realm(s)?
A realm doesn't seem to be specified in the form of an URI or even a regular expression of an URI, it's a value the interpretation of which appears to be left to the HTTP client application. Of note, a "Protection Space (Realm)" is defined, quoting:
A protection space is defined by the canonical root URI (the scheme and authority components of the effective request URI (see Section 5.5 of RFC7230) of the server being accessed, in combination with the realm value if present.
The above is all well and good, but it doesn't facilitate client mapping realms to URIs that may require authorization.
Say my Web server returns a response with status code 401 and the WWW-Authenticate: Bearer realm="The hangout" header line, for a request with a given URI, let's say /foobar. That makes it obvious that subsequent requests to the particular URI must include Authorization header line corresponding to solved challenge (as the client authenticates the user). No problem there. But what about e.g. requests with URI(s) that have the same pathname - those starting with /foobar/ -- is there an implication here that the same Authorization value is expected for these as well? What about entirely unrelated URI pathnames [on the same server]?
It would seem beneficial for the kind of authorization negotiation HTTP already does, to somehow relate or facilitate said relation of realms to URIs. But maybe I am missing something very obvious. Does HTTP do something along of what I am describing? Does it facilitate it in any way, at least, beyond leaving it entirely to the application? How would one realistically let the client determine which authorization bearer to send for which requests? Must it always get a 401 and a challenge response first, before knowing for sure requests to the particular URI and only said URI, must include related authorization bearer?
HTTP is a stateless protocol that deals with a request-response pair. The protocol does not deal with any information that would describe the concept of a "page", "site", "application", etc. Even though it deals with hypermedia, the protocol itself doesn't go beyond the concrete request. This means that you won't get any information from the protocol itself about any other paths under the same domain that are in the same authentication realm. This is left to the documentation of APIs or websites.
It seems to me that your research is centered on one type of authentication process that we call basic auth, know they are some other ways to authenticate a user and that they might suits your needs better as basic auth is kinda old as you can see on that RFC you linked.
To my understanding, the principle behind basic auth is to have a simple process based on challenges. When your client asks for a resource and that resource is protected by authentication, the server responds with a challenge : 401 Unauthorized with a header WWW-authenticate: Basic realm="some realm". The client then know the resource is restricted and depending on the realm, knows if it can have access (or asks the user for credentials for that realm), and try to access with a basic auth header : Authorization: Basic viFWGrwehryfviehtNRBRGWrwGERThRGE. You then repeat that process every time you need a resource.
HTTP and basic auth don't implement any sort of deeper and more complex system for authentication like you're searching for. It's one of the simplest system as its name implies and has not a lot more to offer. I'd even add that it's one of the riskier way to authenticate a system (even using SSL cert and cert pinning) as the client must send credentials for every single authenticated resource request.
In case you want to search other ways to authenticate requests, here are some :
OAuth (2.0) (most secured and complex)
Bearer (JWT or session tokens)
API keys
I have a api url like below in my mvc4 app
http://localhost:15839/api/mydata/getdata/3365895543/PROBLEMDATA/myotherparam
Now client is consuming the above url to send httprequest. In response api is sending back a response. but in PROBLEMDATA of the url user is sending bad characters that are giving me Bad Request - Invalid URL. I can't force my client source to encode data. i need to handle it in my web api and give back my client a string "Unsucessful". I have seen this webapi cycle wondering at which point I should handle this. probably at http message handler but How?
I may need to follow this. but Register(HttpConfiguration config) also doesn't get hit
I believe you can capture this globally by overriding the application_error method. From there I suppose you could produce the "unsucessful" response or pass the request along to be handled at the controller level.
Take a look at this question as well.
I have a web service REST API on a secure ASP.NET website which requires a login to work. What is the most secure way to request the username/password programatically? (just adding a ?username=me&password=mysecret to the URL doesn't seem all that secure to me (even though this is a HTTPS connection).
There are several ways to achieve what you need:
[WRONG WAY] One could pass the username and password along with the query string. In theory there is nothing wrong with this practice, but such a URL (http://example.com?username=me&password=mysecret) is usually cached by browsers, proxies, etc and thus leverage a potential risk that someone else can access to your protected data by using these stored data.
[GOOD WAY] In order to remove "almost all" risks related to caching abilities of browsers, proxies, etc. and moreover in order to use standard features of the HTTP protocol, you have to deal with the special HTTP Authorization header.
The HTTP Authorization header :
If you are using HTTP S connections, then you can use the Basic Access Authentication method.
The Authorization header is constructed as follows:
Username and password are combined into a string "username:password".
The resulting string literal is then encoded using Base64.
The authorization method and a space i.e. "Basic " is then put before the encoded string.
For example, if the user agent uses 'Aladdin' as the username and 'open sesame' as the password then the header is formed as follows:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
If you are using HTTP connections, then you should use the Digest Access Authentication method. Because it's more complicated and useless with HTTPS connections, I let you read more about it if you want (here maybe).
In the data model behind my RESTful API there are several entities with the CreatedBy/ModifiedBy fields. The only access to this data is through my API, and as such, the fields should be populated with the user id of the user making the request to my API.
I have considered either adding these fields to the models exposed by my API or expecting a request header containing the user id on all PUT/POST/DELETE requests. I would be interested in any opinions as to which approach is best, or any other approach.
I like the idea of providing it in the header since it is necessary for every request and I am wondering if there is a standard request header to contain the information, or a common x-header.
I have seen the from request header; however, it seems to be defined as the email address of the user making the request and I need to pass the user id.
In our current implementation, we use the authorization header to authenticate the calling application with the API, and not for a specific user.
Which header would you use to pass information to identify the user making a request?
You can extend the Authorization header to add your own parameters. Both the Digest and OAuth authorization schemes support parameters. The Basic scheme already have the user credentials readable. Something like:
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131200",
oauth_nonce="wIjqoS",
oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D",
xoauth_user_guid="alganet"
Yahoo! does something similar with their OAuth implementation, but in another context.
http://developer.yahoo.com/oauth/guide/oauth-accesstoken.html.
However, if these fields are shown or exposed somehow in your public API, they belong to RESTful resources and should be represented always in the body, not the headers. If you GET the username in the message body, you should POST the username using the message body as well.
Assuming you can use HttpClient
HttpClient client = HttpClientManager.getNewClient();
HttpMethod get = new GetMethod(...);
get.addRequestHeader("x-newHeader", "value");
more here
OR using URLConnection using setRequestParameter
I have been toiling over HttpURLConnection and setRequestProperty for 2 days so far and I cannot get this webpage to Post and return the page I desire. This is what I have so far...
...
String data = URLEncoder.encode("acctno", "UTF-8") + "=" + URLEncoder.encode("1991462", "UTF-8");
URL oracle = new URL("http://taxinquiry.princegeorgescountymd.gov");
HttpURLConnection yc = (HttpURLConnection) oracle.openConnection();
yc.setRequestMethod("POST");
yc.setRequestProperty("Content-Type", "text/html; charset=utf-8");
yc.setRequestProperty("Content-Length", "19004");
yc.setRequestProperty("Cache-Control", "private");
yc.setRequestProperty("Set-Cookie", "ASP.NET_SessionId=v5rdm145zv3jm545kdslgz55; path=/");
yc.setRequestProperty("X-AspNet-Version", "1.1.4322");
yc.setRequestProperty("X-Powered-By", "ASP.NET");
yc.setRequestProperty("Server", "Microsoft-IIS/6.0");
yc.setDoOutput(true);
yc.setDoInput(true);
OutputStreamWriter out = new OutputStreamWriter(yc.getOutputStream());
out.write(data);
out.flush();
//out.write(data);
out.close();
...
It returns the same page defined in URL. it doesn't send me the requested page which should have an ending /taxsummary.aspx
It looks as if the asp takes the post data and generates an HTML unique for each parameter given. How do I give it the correct parameters?
Your code looks fine. I believe it sends POST correctly. I think that the problem is not here. When you are using browser you first perform at least one HTTP GET to arrive to the form. When you are doing this the server creates HTTP session for you and returns its id in response header Set-Cookie. When you are submitting the form using browser it sends this header (Cookie) back, so the server can identify the session.
When you are working from java you are skipping the first phase (HTTP GET). So the first thing you are doing is POST while you do not have session yet. I do not know what is the logic of this ASP page but I think that it just rejects such requests.
So, first check this guess. You can use plugin to Firefox named LiveHttpHeaders. Install it and perform the operation manually. You will see all HTTP requests and responses. Save them. Check that the session ID is sent back from server to client. Now implement exactly the same in java.
BTW often the situation is event more complicated when server sends multiple redirect responses. Int this case you have to follow them. HttpConnection has method setFollowRedirects(). Call it with parameter true.
BTW2: Apache HttpClient is a perfect replacement to HttpConnection. it does everything and is very recommended when you are implementing such tasks.
That's all. Good luck. Sometimes it is not easy...