I'm implementing http authentication using basic schema for my server.
Sever sends a 401 response to client and then browser will pop up a window asking for credentials. And then browser will send username/passwd in Authorization header.
The question is, when browser opens the link for a second time, Authorization header was included in the request header but there was no pop up window, seems these credentials
were remembered(cached).
any one knows how to control this? what to do if I need user input passwd every time? what to do if I need to set a valid duration for this cache?
Great thanks!
You can't do it manually. Read here
Related
I've just started working on an aspx web from login page for AspNet.Identity.
I have my fields, username and password (textmode="Password") and a submit button (asp:button) as usual with my code behind to do login, etc.
My question is, when my user clicks submit, how is the password sent to the server? Do I need to be on SSL to ensure that the password isn't sent in cleartext?
Edit
StackOverflow's login page isn't over HTTPS - how do they (and other sites that don't use HTTPS) manage password transmission?
One can say that all data submitted from the browser is sent in cleartext (that is, neither browser itself encrypt it, nor when data arrives to your server-side script it requires decryption). All the encryption (if any) is performed at the protocol level.
Plain HTTP doesn't encrypt any information sent over it, which allows for simple inspection (man-in-the-middle attack, eavesdropping). On the other hand, HTTPS creates a secure channel over an otherwise insecure network and protects from said attacks reasonably well.
One caveat to that is using GET to send data to the server. This information can easily end up in server logs.
Depending on the form method GET or POST values are sent to the server.
By default in asp.net the form method is POST so it is send in the body of the request.
If the form method is GET then it sent in the url.
Edit 1
When you use HTTPS the channel is secured. But some time it can be slower than HTTP because HTTPS requires an initial handshake which can be very slow.
Some useful links
Difference between http and https
HTTP vs HTTPS performance
Main problem is that if anyone is able to listen to the traffic from your client to your server, then they will also be able to manipulate what your server sends to client. This issue invalidates all attempts to do some javascript magic to hide it out will be lost effort.
In other words, there is for the time being only SSL to help you out.
I found a strange thing when i'm coding a net-spider to a specific website.
I used fiddler and chrome(as well as other web-browsers) to log-in a website(HTTP, not https) and get all package(as well as the cookie) that sent and received:(
first package 'Get' to request the log-in page and the cookie, then use the cookie received to request verification code and some other pics. and then send login request with userid, password and verification code to server and server response with correct info)
Then I log-out and Clear all Cache and Cookie and use Fiddler to Relay(Simulate) the whole process (Since I know all packages' format that i should send): request the log-in page to get cookie, use the cookie to request all pics( auth code image included), and then use the cookie and auth code to request login(userid and password are correct)...but failed.
I'm sure the failure is not caused by invalid userid or password or auth code, and i believe there is nothing special on the front-end(html,script are checked), but it puzzled me a lot how can the server tell i used browser or not in back-end..
I'm not request anybody to solve the specific problem. i'm just wanna know DOES ANYONE HAS HAD SIMILAR PROBLEM i described?
the specific website is not important and i must say the whole practice is completely harmless! i'm not doing any hacking stuff, on the contrary it will help some people.
======================================================
I've finally figured out the reason: the log-in page has a hidden input() and i carelessly overlooked that since its value looks almost the same every time. Web server can not detect replayed log-in attempts if we simulated all necessary HTTP request packages.
Thank you guys~
Servers cannot magically tell whether they're talking to Fiddler or not.
If Fiddler and your client are sending the exact same requests, that means that the server in question is using a "one time token" (sometimes called a nonce) in its login form. If the server ever sees the same token again, it rejects the logon. Sometimes the nonce isn't sent directly, and is instead used in the computation of a "challenge-response" as occurs in authentication protocols like NTLM. In other cases, the nonce is a CAPTCHA, which helps prevent you from using a bot to automatically log in to a site like this.
Unless you can share more details of the target site (or a SAZ file of the login process), it's unlikely that folks will be able to help you.
I am trying to invoke an SSL based Report server url from within a flex application. I cannot enable Anonymous authentication due to SQL 2008 R2 RS. I am passing credentials with the header by adding Authentication Basic encoded(uname:pwd) header.
The first call that goes out as post comes back with a valid response and my toolbar on top of reports show up fine. But the subsequent calls that the report server url makes internally to get style sheet and the main content etc goes out without the Authentication header, so I get a response back with Unauthorized and user is prompted to enter uname/pwd again.
Is there way to keep the credentials in the session.
No, you will have to send the credentials with every request.
Edit
So I assume your call opens a new window (HTML) where your report will be rendered.
The credentials for Basic Authorization is requested once by the browser first, it keeps it on memory and sends it for you on the next requests.
Try opening a new window and setting the credentials to the browser first, not to the request. Call your link and the browser will take care of that for you.
If I have a Selenium test which is currently logged in (with HTTP Authentication) to a particular website, how can I cause the remote browser to forget the current authentication so that I can log in as a different user (while remaining within the same test)?
Is this basic authentication? If it is, you can modify the basic auth header in your request to log in as a new user. You'll have to use Selenium server as a proxy in order to modify the request headers, however.
It depends how you are handling authentication.
If you are doing it via a cookie that gets checked server side you could do deleteCookie or if you want to delete all of them on the page you could do deleteAllVisibleCookies
If you are keeping it within a JavaScript you could just use getEval and delete whats in the variables.
The question that I have is very basic: Is there a way to inform the web browser that the content of the cookie has changed?
I don't want to keep looking at the file and check if it has been updated because it'll cause performance degree on my app.
Thanks in advance!
It's always the job of the server to "push" the new cookie to the browser (in ASP.NET, by setting Response.Cookies("cookie_name")).
I'm not sure to understand your concern, only your application can know that the user's cookie needs to be changed, but it's usually not stored as a file on the server.
You would probably have to check for the Cookie or Set-Cookie http headers that come with the ASP page whenever it reloads in your application, though this would not account for changes made by javascript.
If the ASP page is refreshing each time a cookie changes, that is likely to be a much larger overhead than the WPF reading the cookie from the disk.
Well, since the ASP page needs to be active in order to SET the cookies, why couldn't you just use a HttpClient to request the cookies in your WPF app and on the server, set the cookies. Then send HTTP Response depending on whether or not you set the cookies. If you receive a 200 OK response, you can know your cookies are set. If there's an error, send a 500 Server Error back.