I am using Restlet with Digest Authentication. Works well. Except I want to make it a bit more ajax/Javascript friendly by avoiding the browser's authentication dialog pop up when a 401 is first sent back.
This is what I think will work:
User/pass obtained using a textfields and stored in javascript object.
Ajax call to secure resource.
Reselt sends back non-401 code (say 406) with Digest Auth info.
Javascript catches code, packages request/user/password into hash, sends to restlet.
a) Will the above work?
b) How do I send a different status code using Digest in Restlet?
Yes, you have to return non-401 response, since you cannot change the browser behaviour in that the browser will always display the popup.
see also How to prevent browser to invoke basic auth popup and handle 401 error using Jquery?
you change the response by modifying/overriding the DigestAuthenticator and setting a different response, or use a filter that will detect a 401 and switch it to another status.
Related
I have an Angular app with a route say /register which can be accessible on http://xyc.com/register
I want to make a GET call to this url and pass a header in that request.
Now, I want my angular app to be able to read header from the request and store it in cookie.
I am not sure where and how to retrieve the header from the request in my Angular app? Should I ideally create an interceptor for this and do request.headers to get the header I want? I tried it like this:
export class SomeInterceptor implements HttpInterceptor {
intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
console.log("headers = " + JSON.stringify(request.headers));
...
...
}
}
Not sure if this is the right approach?
Then, I wanted to test (from browser) if the header is retrieved properly by sending a GET request to the URL and seeing if the header prints using console.log. For this I tried to use a JSP to send a GET request to this URL (along with the header) in order to test if the header is retrieved correctly in my Angular app. But I am not sure how to do it.
In my JSP code, I tried the following:
response.setHeader("myHeader", "test-header");
response.setStatus(HttpServletResponse.SC_MOVED_TEMPORARILY);
response.setHeader("Location", "http://xyc.com/register");
However, I don't see my header printed. Not sure if my approach to read the header is wrong or the way I am testing is wrong. Any help?
Cookie ideally is way for server to send data to browser to keep track of anything that server wants to remember. E.g. Authentication token or anything that can track session of user. What you are trying to do is other way round. I would have ideally set cookie as a part of response from server than actually reading at browser and setting it there. Ideally in most of the cases browser too does not need to explicitly set, as once set it becomes a part of every request that is send.
I'm implementing a temporary and very simple token-style authentication mechanism for an application.
The idea is very simple. Whenever a user logs in to the application, a token is returned to the client, which stores it in the sessionStorage data structure of the browser.
Now, whenever I do a request through AJAX I can send the token with the request and the server can verify if this token is associated with an authentication or username. If it is, it parses the request normally, if not, a error page or the initial page is returned or displayed.
I'm not sure if this is the way that token-style authentication and authorization is implemented in real or serious applications, but I've now no idea how to send the token when doing GET requests by just clicking on the link of a view.
My only idea would be to intercept the get requests so that I can fill them with the token, but this all seems to be quite odd, and I've already a lot of links and views.
Search for Json Web Tokens and for implementations on java. This is exactly what you need.
If you want to send to the user some sensitive data inside the jwt, use Json Web Encryption.
You can send that token on each request header or as a request parameter
You can set a cookie, ensure to set it httponly (ans secure if you are on an https site) and read the cookie on every request that reach the server.
You can use JWT token (see https://jwt.io/introduction/). JWT is basically a JSON data structure. Usually, the token is passed along in the authorization http header.
I'm using java.net.HttpURLConnection.
I first write the body of the post request to the OutputStream associated with the URLConnection object.
After I have done that, I close the OutputStream and then call getInputStream() or getResponseCode() or getHeaderFields(). That's when I find out if the provided credentials were considered valid or not valid.
This is problematic, because I don't want to make the same post request again (and have to re-upload its contents, which could include large files) in the event that the user credentials were rejected for some reason.
Since an exception is thrown if there is an attempt to call getOutputStream() after getResponseCode() or getHeaderFields() have been called, how can I ensure that the user credentials were accepted before attempting to upload the data?
Is there a way around this or is it just the way the server is configured?
The short answer is: You can't do that.
Basic auth is stateless. When you're doing a POST/PUT the user credentials are sent as headers for that HTTP request. They are not processed until the entire operation is complete (i.e. after you've sent the data payload).
In order to do what you're talking about you'd need to write a web service that managed login and file/data uploading separately through session management, allowing you to first authenticate (returning a session token of some sort) then send the data via a separate HTTP request.
Edit to add: In reality, you could hack your way around this by simply doing a GET to something that also requires auth. If it succeeds, you know the POST will also succeed baring the credentials being invalidated server side between the two requests. I would not advise this, but it would work.
I am working on a Web application and need to pass data across HTTP redirects. For example:
http://foo.com/form.html
POSTs to
http://foo.com/form/submit.html
If there is an issue with the data, the Response is redirected back to
http://foo.com/form.html?error=Some+error+message
and the query param "error"'s value is displayed on the page.
Is there any other reliable way to pass data across redirects (ie HTTP headers, etc.).
Passing the data as query params works but isn't ideal because:
its cleartext (and in the query string, so SSL cant be relied on to encyrpt) so I wouldn't want to pass sensitive data
URIs are limited in length by the browser (albiet the length is generally fairly long).
IMPORTANT: This platform is state-less and distributed across many app servers, so I can't track the data in a server-side session object.
From the client-server interaction point of view, this is a server internal dispatch issue.
Browsers are not meant to re-post the entity of the initial request automatically according to the HTTP specification: "The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD."
If it's not already the case, make form.html dynamic so that it's an HTML static file. Send the POST request to itself and pre-fill the value in case of error. Alternatively, you could make submit.html use the same template as form.html if there is a problem.
its cleartext (and in the query string, so SSL cant be relied on to
encyrpt) so I wouldn't want to pass sensitive data
I'm not sure what the issue is here. You're submitting everything over plain HTTP anyway. Cookie, query parameters and request entity will all be visible. Using HTTPS would actually protect all this, although query parameters can still be an issue with browser history and server logs (that's not part of the connection, which is what TLS protects).
I think using cookies would be a reasonable solution depending on the amount of data. As you can't track it on the server side (by using a sessions for example, which would be much simpler)
You can store error message in database on server and reference to it by id:
http://foo.com/form.html?error_id=42
If error texts are fixed you even don't need to use a database.
Also, you can use Web Storage. Instead of redirection with "Location" header you can display output page with this JavaScript:
var error_message = "Something is wrong";
if( typeof(Storage) !== "undefined" ) {
localStorage.error_message = error_message;
else {
// fallback for IE < 8
alert(error_message);
}
location.href = "new url";
And after redirection you can read localStorage.error_message using JavaScript and display the message.
I'm trying to create an android app to check my tests scores of my engineering school. In order to download the Word containing the scores, I need to login to the portal.
I thought it would be simple to do it by sending a POST request.
After bypassing the problem of the self-signed certificate (or whatever) thanks to the code on this page : Self-signed SSL acceptance on Android
I still get an 500 error while trying to send any POST request to the login page, which is here : https://e-campus.hei.fr/ERP-prod/pc_mv_login.aspx
I tried various codes from the web to send the POST data (especially How to do a HTTP Post in Android? this one). And even on a pure java app, I get a 500.
When I point the URL to another testing page, I manage to get it working, but not on https://e-campus.hei.fr/ERP-prod/pc_mv_login.aspx
Could anyone explain to me why it doesn't work or help me get rid of this error ?
EDIT:
This is what is being sent through my browser (According to chrome developper tools)
__EVENTTARGET:
__EVENTARGUMENT:
__VIEWSTATE:dDwxNDU4ODc4MDI5O3Q8O2w8aTwwPjs+O2w8dDw7bDxpPDE+O2k8Nz47aTwxMz47aTwxNT47aTwxNz47aTwxOT47PjtsPHQ8cDxwPGw8VGV4dDs+O2w8SWRlbnRpZmlhbnQgOjs+Pjs+Ozs+O3Q8cDxwPGw8VGV4dDs+O2w8TW90IGRlIHBhc3NlIDo7Pj47Pjs7Pjt0PHA8cDxsPFRleHQ7PjtsPExhbmd1ZSA6Oz4+Oz47Oz47dDx0PDt0PGk8Mj47QDxBbmdsYWlzO0ZyYW7Dp2Fpczs+O0A8ZW47ZnI7Pj47bDxpPDE+Oz4+Ozs+O3Q8cDxwPGw8VGV4dDs+O2w8Vm91cyBuJ8OqdGVzIHBhcyBhdXRvcmlzw6kgIMOgIHZvdXMgY29ubmVjdGVyLjs+Pjs+Ozs+O3Q8cDxwPGw8VGV4dDs+O2w8Q29ubmVjdGVyIDo7Pj47Pjs7Pjs+Pjs+Pjs+inmhCwE9zfymuEXDXGORShkB1GI=
Username:******
Password:******
Langues:fr
Button1:Connecter :
This is the string that i send :
String parameters = "__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE="
+ URLEncoder
.encode("dDwxNDU4ODc4MDI5O3Q8O2w8aTwwPjs+O2w8dDw7bDxpPDE+O2k8Nz47aTwxMz47aTwxNT47aTwxNz47aTwxOT47PjtsPHQ8cDxwPGw8VGV4dDs+O2w8SWRlbnRpZmlhbnQgOjs+Pjs+Ozs+O3Q8cDxwPGw8VGV4dDs+O2w8TW90IGRlIHBhc3NlIDo7Pj47Pjs7Pjt0PHA8cDxsPFRleHQ7PjtsPExhbmd1ZSA6Oz4+Oz47Oz47dDx0PDt0PGk8Mj47QDxBbmdsYWlzO0ZyYW7Dp2Fpczs+O0A8ZW47ZnI7Pj47bDxpPDE+Oz4+Ozs+O3Q8cDxwPGw8VGV4dDs+O2w8Vm91cyBuJ8OqdGVzIHBhcyBhdXRvcmlzw6kgIMOgIHZvdXMgY29ubmVjdGVyLjs+Pjs+Ozs+O3Q8cDxwPGw8VGV4dDs+O2w8Q29ubmVjdGVyIDo7Pj47Pjs7Pjs+Pjs+Pjs+inmhCwE9zfymuEXDXGORShkB1GI=",
"UTF-8") + "&Username="
+ URLEncoder.encode(mUsername, "UTF-8") + "&Password="
+ URLEncoder.encode(mPassword, "UTF-8")
+ "&Langues=fr&Button1="
+ URLEncoder.encode("Connecter :", "UTF-8");
HTTP error 500 just means that the server side code failed. It has a bug, for example a NullPointerException was been thrown over there. If the response body doesn't contain anything sensible (e.g. a stacktrace) so that you could learn how it is caused and so change the request accordingly, then your best bet is to contact the server admin and report about this bug in the server code and ask how to correctly perform a programmatic login.
If that is not an option for some reason, then you should doublecheck if you don't forget to send a specific cookie, header and/or parameter. Probably the server side code was expecting it, but it was null and the code was buggy and hence it totally broke with a 500. I'd suggest to use Firebug to track the entire HTTP traffic and compare it with the headers/parameters you've set. Probably you need to send a specific cookie back? Or you need to send the name=value pair of the submit button? Etcetera.
Update: you're sending the wrong __VIEWSTATE value along. The website runs on ASP.NET MVC which is a component based MVC framework (like as JSF in Java EE). It stores the component tree as "view state". You should not send a random/non-existing/invalidated view state back as paramter, but a valid one. You need to rewrite the HTTP client so that it first fires a GET request on the page with the form and then use a HTML parser (Jsoup?) to extract the value of the hidden __VIEWSTATE input field and finally fire a POST request with exactly that value (and exactly the same cookie in the request header!).
Like as in JSF, the view state is part of CSRF attack prevention. You cannot submit the form without first requesting the form from the website itself in the same session.