In IIS I've got:
http://myserver/myapplication
http://myserver/reports
The reports app is reporting services in fact which uses windows authentication. myapplication is an asp.net application that uses forms authentication.
The server is outside the company domain. If I access the reports first and type in the user and password(local credentials created on the server) when prompted I can access the reports page, no problems. If then I go straight to my application's login page and try to login, the login page refreshes without doing anything. This always happen in IE 6. In IE 7 it happens intermittently. Does not happen in Firefox or if Fiddler is running in the background which seems to fix the problem on the fly.
I used wireshark to see what's going on and found that IE 6 send the windows authentication token obtained from the reports app to myapp. That was the only difference between IE and Firefox. IIS seems to freak out and simply interpret my POST to the login page as a GET and return.
If I add windows authentication to myapplication in IIS everything seems to work fine with any browser.
Why is this happening? A bug in IE or am I missing something?
It's sorta a bug in IE, and sorta a bug in the design of NTLM/Negotiate (aka Integrated) authentication over HTTP.
NTLM/Negotiate are connection-oriented auth protocols, which HTTP wasn't really designed for. As a result, when you require this auth mechanism for one page on your server, IE will typically assume that other pages on the server have the same requirement.
Furthermore, for performance and security reasons, if IE expects a Negotiate/NTLM challenge for a given POST request, then it will first send a 0 byte POST, expecting the server to return a HTTP/401 challenge to which it will authenticate and then properly send the POST body.
However, in your case, the folder which doesn't require Integrated auth gets the 0 byte POST and says "Hrm, weird, a 0 byte post. Okay, HTTP/200, here's the page as if you'd used GET."
Because IE never gets the 401 challenge it expects, it never actually sends the POST body.
(Fiddler may confuse you a bit due to how HTTP connection reuse works).
The workaround is to ensure that if you're using Integrated auth on the host, use it everywhere.
Related
Very strange issue I am facing from past few days. I am just able to login to any application on my domino server using "Mozilla Firefox". If I use any other browser (Chrome, IE), it just stays on the login page with absolutely no information, everytime I login in it again shows back the login page with no error message at all. Its quite strange since its working perfectly fine on Firefox.
I am not sure, but I somehow feel that it has something to do with the configuration. Would really appreciate if someone can guide me here.
Edit 2:
Selecting Single Server, does work, that was the simplest solution; as of now we do not need "Multiple Server".
However, we do not use any other "Internet Sites", I tried to remove the organization field, however, that lead me to "An R5 web SSO configuration already exists", which in turn lead me to here. However, I am able to move further here with "Multiple Servers".
Edit 1: Based on the answers, here are the things I tried. Please find below the snapshot of each of it for better understanding..
LTPA Token Configuration
Server Configuration for LTPA Token
Network tab - before login
Network tab - after login
Console shows nothing before or after login, neither does the server log files. Also, I am able to access the names.nsf database with absolutely no problem. Lastly, I try to access a database with no anonymous access and hence get redirected to the login page (however, as question mentions, it just stays in loop)
Ok, you may need to provide a little more information.
Are you doing a "normal" login using domcfg and a "...&login" url? Or are you trying to open a design element in a database that has no access to "anonymous" and thus redirects to the login?
You can easily check that "standard" login by opening the url: http://yourserver.com/names.nsf?login. Does it behave differently in the browsers? If not then your server setup etc. is Ok. Then you have to look at the solution that tries to log you in.
Your first place to check is in the browser's console. Are there any errors in there? E.g. some client side Javascript that stops running? Check the network tab when you inspect the console/developer tools. Does it send the right requests?
Another step is to check the console/log files on the server. If you have grown your own solution then you may want to add some simple print statements to prove that it sends what you think.
Finally, you can use a network sniffer (like wireshark) to see exactly what is sent between your browser and the server.
/John
A login- page that reloads itself after every login without a message like "Wrong username or password" or similar normally happens if the session authentication for the server is configured as Multiple Servers (SSO) (Found in Server document on Internet protocols-Domino Web Server, if Internet Sites are Disabled or in Internet Site document, if they are enabled).
In that case an LTPAToken has to be configured as well, and this token has to have a configured domain name. Whenever you try to access a server with SSO enabled using a hostname without domain or with a different domain, then exactly this will happen: Login- Page reappears after every try to login.
Example:
if the servername is myserver with ip 10.10.10.1 and the LTPAToken is configured for ".mydomain.com", then the only valid URL for login is:
hxxp://myserver.mydomain.com
Trying hxxp://myserver or hxxp://10.10.10.1 will result in exactly the described behaviour.
It is important to know, where to look for the "right" SSO- Configuration document.
If the server is configured to use "Internet Site documents" (Server- document, Basics- Tab, Load Internet configurations from Server\Internet Sites documents enabled) , then the SSO- document needs the field "Organization" to be filled. In that case you will find it in the Web\Internet Sites- View of the domino directory.
If Internet Sites are disabled, then the Field "Organization" has to be empty. In that case you find the SSO- document in the Web\Configurations view.
I'm trying to develop a native OS X app that uses the Nest API. Unfortunately, their client registration only accepts "https://" URIs for the redirect-URL. Since there's no server involved in this (other than Nest's server), I need to redirect to my app. To do that, I need to be able to redirect to an arbitrary URI.
I tried to send this feedback to Nest directly, but they don't seem to have a support contact or bug reporting available.
Am I missing some other authentication approach for this type of use? It's a similar problem on iOS.
Thanks!
Nest can only assure in the normal browser world that HTTPS is secure. Yes, there are other application protocols that are secure, but the standards are not well defined. As such the return URIs are limited to HTTPS and HTTP://localhost (It is assumed that is someone has control of your machine, they can also intercept HTTPS calls)
Mac OS and iOS have a relatively simple workaround for this that is demonstrated in Nest's iOS NestDK sample code. The key parts are:
In line 30 of constants.m you will see that RedirectURL is defined (when running this sample code, you might want to change this to your preferred URL, likely something your company already controls for further security)
And in line 126 of NestWebViewAuthController.m where the app is checking if the WebView is trying to load our dummy redirect URI. If so, it captures the parameters and tries to get a token that can be used with the Nest API.
I have a web site that accomplishes user login via ajax call over https. Obviously the request contains the password. Playing around with Firefox developer tools I noticed that I can inspect any network requests coming from my page including the request body ... and there is my password. I assume the request is being encrypted since its over https but the developer tools still shows it as plain text. Am I missing something? If a user logs in on a public machine and forgets to logout anyone can use developer tools to grab their password. Thanks in advance for any help you can provide.
-Mike
Everything is functioning by design – there's nothing wrong.
The browser's dev tools are intended to allow the user to inspect everything that's happening in the page – without that functionality, they'd be pretty useless. The dev tools' network tab shows HTTP data before it is encrypted.
In the public machine scenario, remember that the dev tools only show network requests that happened after the tools were opened, so an attacker can't just open the dev tools after the user leaves with your page up and see the plaintext auth request.
I can inspect any network requests coming from my page including the request body
No you can't - that's not yet network traffic - that's a HTTP datagram which is then passed through the SSL layer before it gets to the TCP stack.
If a user logs in on a public machine and forgets to logout anyone can use developer tools to grab their password
No, because unless the page developer is doing really stupid things, the browser does not store the information - you could only see it because your browser was configured to intercept the information and store it temporarily. But having said that there are a large number of things which can cause the browser to store authentication tokens - auto complete and password managers for a start (the latter vary greatly in the quality of their implementation, the former has little protection against disclosure). Authentication tokens should never be sent as GET parameters hence should not be visilible from the browser history.
I'm using node/express to make a pure backend api. My front-end (angular.js) is hosted on a separate server. I have a few lines of middleware for every request to allow CORS.
If I start chrome with -args --disable-web-security flags, everything works great!
However if I start it normally, cookies seem to not be getting set in the browser, and therefore sessions on the node side aren't kicking in. This is the same for safari/mobile safari/etc.
I've tried browser options such as "accept all cookies"/"never block cookies". I thought maybe browsers don't like localhost but this is the same behavior on localhost and on actual hosted domains.
The flow is:
I login and the session is set with an id, on success the frontend is directed to the next page. This works, and I console logged req.session.id and it's correct.
On the next page a request is sent, the node server is configured to use the id in the session for this request. With safari/mobile safari/chrome the req.session.id is suddenly empty. With chrome -security disabled, the req.session.id is still correct and behaves just like it should.
please refer to this answer that covers cross-domain cookies and session: Using Express and Node, how to maintain a Session across subdomains/hostheaders
At work, I have IE8 on XP, calling a .net 4.0 web app on WinServer 2003 with IIS6. IWA is turned on. When I call the page, the initial aspx page call of course will show 3 lines in Fiddler. First is anon request, second has some AUTHORIZATION:NEGOTIATE header, and then the 3rd has a longer value for the same header (probably a token). The first two result in 401 errors, the last is 200 success. But this is expected.
The issue: When the following resource files (CSS, JS, images) get called, mostly all of them (but not all) go through the same 3-step call. The first 2 are 401 errors, then the 3rd gives me the 200 code and the content.
Is this normal? I thought just the first call of the page itself is the only thing needing the 3-step process.
FYI- we had OAM and WebGate on the server, but we uninstalled it and we are still getting this behavior. Is it possibly the app pool doesn't have it's identity/domain ID setup right? I really don't want to turn the style, script and image folders on Anonymous.
This is correct if your server is configured to protect any resource. Since HTTP is stateless, every request has to be authenticated. This can be avoided if a session cookie is used which memorizes the auth. Otherwise this will happen every time.