I am writing SpecFlow/Selenium tests with headless Google Chrome in --incognito and I would like to know if the headed or headless instances will be more separated than when I use Chrome as a desktop browser.
Specifically, I have two tests running at the same time which require accessing the same site and performing the login steps of two different users. Will those browsers have unique, separate logins or will they behave like incognito does for me as a user - that is, will the first login be recognised by the second instance?
They are both completely isolated from eachother.
You can verify this by running either, and then checking for stored cookies or login information.
To answer directly, no, the first login will not be recognized by the second instance.
Related
There are lots of variations of this question/problem and it seems like this something that a lot struggle with. At a high level, I am trying to hit a site that uses IWA for auth. In more detail, we are trying to hit the site from a test VM. The test VM does not have a user logged in, so when the browser is opened by selenium or another driver, there is no IWA authenticated user. The session just times out each time.
I have tried for almost 2 weeks now and can't find a solution. Things that we have tried.
Opening the browser as a specific Chrome prolile (this doesn't seem even remotely possible, but I still tried it unsuccessuflly)
Enabling impersonation in IIS/Web.config and granting the permissions to this domain user (site still opens as no user using selenium, or opens as my account if I RDP to the box)
Disabling auth in the application, but that goes against what flows/features that we'd like to test
enabling and using proces.start in the selenium project but errors would arise about permissions creating folders on the VM
Auto login with AD account when VM boots up but domain GPO blocks that
From being very new to this and only troubleshooting for a couple weeks, that the approach should be somehow in the test project be able to login as that test user and open the browser/url. I just have not found out how to do that.
What is the best approach when in this situation? Is it possible to have a selenium/C# solution run on a windows machine and initiate a login? If that is even possible, could you pass that to the chrome driver and then the browser?
I have been given a task to sort out a bug in a SilverLight application, however my knowledge of authentication is basic at best so I am quite stuck and looking for help.
The issue is that if a user logs into the application, then opens another browser tab/window and accesses a URL from within the application, this is perfectly acceptable and the system works ok as far as we know. The problem arises when the user logs out of the application from one tab/window and then tries to continue to work on the other tab/window, in which case a variety of errors are thrown depending on what the user does.
We already have a timer in the application to detect connection issues with the database so I thought that checking that the user is authenticated here would be a good start, so I checked for AuthenticationService.User.Identity.IsAuthenticated, but unfortunately that is always true. So I researched and debugged my code and that property is actually set to false once the Logout method has completed, however this doesn't seem to be the case when I debug the application once the user has logged out on the other tab/window.
I have researched on the internet, but all the similar issues I can find are caused by something that isn't relevant, or that I don't understand completely.
The system uses an authentication class which is inherited from FormsAuthentication, but all the Login and Logout functions use the base WCF RIA AuthenticationService service methods.
Could anyone make some suggestions as what could be the issue?
When you log out basically what happens is that the server will destroy your session in the server memory/session state etc. If there is a new request from the same client the server will read the session id cookie and try to match it with one of the existing sessions. If this session will not be found then we will get the exception you are facing.
Having a SilverLight application this is basically a client application which will not send any request to the server until it really requires is ( Service call). I think you should send a log out message to all of your application instances to log out the user also on the client side everywhere else.
Maybe this links will help you
Can silverlight detect or communicate across browser instances?
Writing a javascript file from another javascript
Once again the confusion related to MSDN documentation with respect to Session Management.
I went thru the Session Management Article in MSDN, and found that it is stated in the article that - "we can Store session-specific data on the server for use across multiple browser or client-device requests within the same session."
Can anybody tell me how is it possible. for e.g. if you have two browsers i.e. i)Firefox and ii) Internet Explorer (IE).
Now, If I am running asp.net application (which uses stateserver to manage sessions) in Firefox. And again the same application I ran through IE (without closing firefox session). Is that means that both the browser will share the same session? I guess "NO". Both the browsers will run with their own sessions, which is different from each other.
Secondly, I found that the two statements in the article are contradictory with each other. It says that - "Session state is similar to application state, except that it is scoped to the current browser session" and on other hand it says that - "It Store session-specific data on the server for use across multiple browser or client-device requests within the same session"
So, if its scope is limited to the current browser session, then how it can be use across multiple browsers?
It is a little confusing, but I think you're misinterpreting the statement. They are referring to multiple requests, not browsers or client-devices.
Session is indeed scoped to the current browser session, persisted with cookies or query strings.
In general, sessions are handled through cookies. Each browser implementation (IE, Chrome) has its own cookie store. Therefore, different browser implementations aren't going to be able to share sessions without some significant workarounds.
Multiple instances of the same browser can reference the same session because they all have access to the same cookies. This can be described as "multiple browsers".
I have a few websites which allow both anonymous and window auth users at the same time. Basically if you hit the site with IE or Webkit based browsers on a windows system, the server instantly recognizes your active directory user and group.
In the past I've provided a link to a windows auth only page which allows the current user to login, or bounce back to where they started.
I find the management of this kind of frustrating as I need to make certain that IIS has the correct security settings for that single page after every deployment.
Is there a better way for me to allow a user to elevate from anon to authenticated?
There is no other way to do that elevation automatically. The server can't know that the current user is a Windows user and elevate them, or automatically redirect them to the Windows auth only page. On the other hand, if every user will get through the Windows auth only page, all of them which are not inside the domain will see the challenge/response dialog box (user + password).
As for the management part of making sure that this special page has the correct security settings, you can (and should) automate the check somehow. For example, by querying the IIS metabase for that setting when the application starts (in Global.asax) and if the setting is not there, log it as an email message or so.
Personally I prefer a different attitude - a special "integration/deployment" page which contains a series of tests against my application so I can make sure everything's set up correctly on the server, i.e. NTFS write permissions to certain folders, availability of the SMTP server set in web.config to send emails through, etc.
Note: You're using Windows authentication along with anonymous access. Just keep in mind that if you consider implementing Forms Authentication in the future, a misarchitecture (I don't know if by design or due to a flaw) of IIS 7 does not allow you to set the app to be Forms Authentication and set one specific page to be Windows Authentication. The override just doesn't work and it's very frustrating.
Good luck!
OK, I figured out a fairly nice way to do this...however it's not as elegant as I had hoped since it doesn't work across applications.
Basically, if you create a single page within your Anon + Integrated Auth IIS6 website or virtual directory, let's call it auth.aspx, then you can use this page to prompt authentication.
Go into IIS settings and specify that auth.aspx is Integrated Auth ONLY (no anon). Then create a hidden iframe somewhere on your page. I then created a simple JavaScript action to update the src attribute of the iframe to the auth.aspx page. This forces the browser to try and authenticate using NTLM. Once you enter valid credentials you've successfully elevated your current user beyond the generic anonymous user.
One final touch was to then include a Response.Redirect into the auth.aspx which reloads the current page. Assuming your ASP.net session tokens are set correctly, the page will reload and the user will be authenticated.
So i have a custom CMS running under .Net 3.5 written entirely in c#. The engine is optimized to render for mobile devices, but also server to normal web browsers. It also supports cookieless sessions. Great...
I've chosen not to cache anything (including browser data) in order to control the rendering completely from data. This has been all good until lately.
The engine implements a basic login function that simply logs the user state within a session object.
The behavior is rather strange. User will click through the site no problem. Then login. The login will either go through successfully or just redisplay the login screen, suggesting a cached page being returned or redisplayed... If the login is successful the concurrent page hits will switch arbitrarily between logged in and logged out state... Also suggesting either the session state is not accessible or a cached page being returned.
I have debugged the hell out of the thing.... including using fiddler and the like. When debugging the behavior disappears.
Huh?
One of the sites running on the engine is http://www.wiseguy.mobi (sorry customized for South Africa, so you'll probably not be able to get the password Text Message)!
Ok, so i've been a dumbass...
The issue was related to the fact that my IIS application was running 2 WorkerProcesses. Thus InProc Session state would return different session object states when the user hits either of the worker processes.
This is why the SQL SessionState persistance has resolved it. Either was its set up rather nicely now, and the issues have been resolved...