I'm developing a Scraping app to extract some information from a sit. To get that information I have to be logged in to that site.
So I use Http post and pass the data needed for login using FormData and log in successfully, so I can browse the private content of that site.
My question Is: "How can I tell if the user is logged in?". What is the simple way to do that using session cookies or something like that?
I'm currently checking the connection by sending an Http Get Request to a Url that I know is available to registered users.
So before I try to login again, I use this method "isLoggedIn" to check the connection. But it is not perfect, I mean, it seems a kind o tricky and not the best way to do that.
Currently, I'm using Dio - a Lib to make Http Request in Dart. But I think it's a general Http matter.
Just to register...
I solve that after checking the difference between a 'logged' and a 'not logged in' response. In my specify case, when I did a get request to the login page, it answers with a response that has a 'CUSTOMER_AUTH' cookie setted with a random String, otherwise, this cookie is not present.
So I just check if this cookie is present and if it has a valid value.
Related
Philosophically, I am accustomed to always using GET for HTTP requests that do not alter state, and POST for requests that do. However, lately I have run into some difficulties with this that have caused me to make exceptions. I was curious if there is any non-philosophical downside to using the wrong HTTP verbs, such as security concerns like cross-site attacks.
Exception #1
I wanted to trigger a download of a requested list of files dynamically packaged into an archive. However, the list of files could grow so large that, when encoded as querystring parameters in the URL, they exceeded the url length limit in Internet Explorer. To work around this, I ended up triggering the download with a POST.
Exception #2
There is a button that is always displayed, regardless of whether you are logged in or not, but it can only alter state if you are logged in. If you press it when you are not logged in, you are taken to the login page with a querystring parameter indicating the place you were intending to go next. When you log in, it redirects you there to complete your action. However, the redirect can only generate a GET, not a POST. So we have allowed GETs to alter state in this situation.
Are there any exploits or downsides to these exceptions? Do these allow any cross-site request forgery scenarios that cannot be prevented by checking the referer header?
Answer to question in subject: Yes
Exception #1: A GET request can have a body. You don't have to put everything in the URL
Exception #2: Alter the form to use GET when not logged in and POST if logged in.
Using referer is not recommended. There have been all sorts of workarounds, and some corporate software strip it for privacy concerns.
I highly recommend a token based approach to CSRF-mitigation.
Is there a way to know if the request has been redirected or forwarded in the doGet method of a Servlet?
In my application, when a user (whose session has timed out) clicks on a file download link, they're shown the login page, which is good. When they login, they are immediately sent the file they requested, without updating the page they see, which is bad. Basically, they get stuck on the login screen (a refresh is required).
What I want to do is interrupt this and simply redirect to the page with the link, when a file is requested as a result of a redirect.
Perhaps there are better ways to solve this?
The redirect happens client-side. The browser is instructed by the previous request to send a new request, so to the server it does not make a difference. The Referer header might contain some useful information, but it's not certain.
When redirecting you can append some parameter, like ?targetPage=dowloadpage and then check if the parameter exists. You may have to put this in a hidden field on the login page if you want it to be transferred through multiple pages.
If you're using container managed authentication, then I don't believe you can detect this since the server will only involve your resource once authentication has been completed successfully.
If you're managing authentication differently, please explain.
I'm doing some requests to an API via WordPress, and the API uses SSL connections if they're turned on in the API settings. I'd like to determine whether SSL is turned on or off without having to ask the user if SSL is turned on on their account, and the API does a good job at redirecting, meaning
If I access http://api/endpoint and SSL is turned on, I'm redirected to https://api/endpoint
If I access https://api/endpoint and SSL is turned off, I'm redirected to http://api/endpoint
Now what I'd like to do is see whether a redirect happened or not and record that to my options so that the other requests are fired to the correct URL without any redirections.
So my question is: is there a way to determine the final destination after firing a WP_Http->request() when the request is being redirected?
I can't see any info about that in the response arrays, I only get to see the final response but I have no idea what URL that came from. What I can do is set the redirection parameter to 0 and catch the max redirects allowed error, but that's not bullet-proof, since I still don't know whether the redirect happened from http to https or simply another page under http.
I hope this all makes sense, let me know if you have any ideas.
Thanks!
~ K
check $response['headers'] - they may contain 'location' key.
It all depends on the HTTP library you are using.
See class-http.php(wp 3.0.1) file:
line 1393, http_api_curl action - curl handle available directly to catch anything.
fopen:
check lines 887-888, and $http_response_header variable.
also, try to override processHeaders function as it has an access to raw http headers.
The WP_Http class processes the headers and removes all but the last one. So you could do what jetdog described above. Check the original URL and compare it to the returned $response['headers']['location']. If it is different, than you know it redirected.
At http://localhost/tmp/ I have a form that asks for the user and password (authentication).
After the user posts (hits OK) I want to redirect the user to http://localhost/test/ which uses Apache's Basic AuthType. Happens that the user and password just typed in the form are exactly the credentials to authenticate at http://localhost/test/
What I want is the solution so that the user is not asked for the password in the second address. So far I was able to pass the 'Authorization: Basic "base64_encoded user and password"' with CURL (using GET), and get the response I want (contents of test/index.html, for example). However, that's curl getting the info instead of my browser redirecting there with preauthorization. That is, if I type http://localhost/test/ in the address bar it asks for the password again. Any ideas? Any clarification needed?
The problem is that the authorization state is maintained in the browser, and there's no real way to tell the browser it's authorized.
Most systems rely on a Cookie system, but BASIC/DIGEST HTTP AUTH are HTTP headers. So, only the browser can set those.
I should say, for normal every day requests -- you might (I'm not sure) be able to set the headers in an XHR.
Could you simply set the form submit location to the redirect destionation http://localhost/test/ and take care fo the authentication here?
As an aside, Fiddler is a great tool for debugging this sort of thing
Will's answer points you in the right direction.
In IE at least, it works to send an XHR request (to some throwaway page) with the Username/Password parameters (in the Open() call) set. Doing that will cache this username and password internally for the browser session, and so when you subsequently visit other pages on the server, the authentication SHOULD automatically happen for those pages.
I can't say if this trick works in other browsers or not.
I'm playing with HTTP Basic Authorization. As we all know, when a client gets a 401 error on requesting a page, the client must collect authorization credentials from the users (typically in the form of a pop-up window).
Subsequent requests for resources under that part of the URL will be accompanied by "Authorization: Basic [hash]" where [hash] is the username/password mashed together and hashed.
What I'm interesting in is getting the client to not send the Authorization header even when requesting a resource that previously asked for it.
Three important questions:
Is this possible?
If possible, does this violate the HTTP/1.1 standard (I'm unclear that this case is covered by the spec)?
What browser support this?
Thanks for your time, Internet.
UPDATE: Apparently, this is an apache FAQ and I am SOL. Still, if you've got thoughts on this question, I'd love to hear about it. Thanks.
I don't think this is possible. The authenticated session lasts until the user shuts the browser window, and the browser will keep on blindly passing the credentials with each request under the same path.
Is there any specific reason why you want this functionality?
You can set the user and password in the URL:
http://user:password#example.com
If you use this syntax, the browser will generate the header for you.