I'm making a web application for a customer that has clients who want to put the login to the app inside of an iframe on their web sites. On a succesful login we want to open the app in a new pop-up window, but it seems that the logged in session is only retained inside of the iframe and not in the main window or in the pop-up. This is only a problem in IE, not in any other browser.
Is there a working way to implement this?
The flow is this:
User goes to client's website (www.url1.com)
User logs in to app, which is in an
iframe (from www.url2.com)
App in iframe validates login
App in iframe uses window.open to
open the app in a new, separate
window
EDIT: Fiddler shows that what happens in the iframe is attached to one iexplore process and what happens in the main window is attached to another. This obviously is the problem, can it be worked around?
Setting cookies in an iframe which loads a page from another domain can cause some strange issues sometimes. And if the cookies don't work, chances are, your login won't work either.
To get around it in a previous case, what I had to do is to add a custom http header in either IIS / Code which suddenly made things work.
Sample C# code:
protected void Application_BeginRequest(Object sender, EventArgs e)
{
HttpContext.Current.Response.AddHeader("p3p", "CP=\"CAO PSA OUR\"");
}
Try to use Fiddler to check if the cookies created by the login page (in the iframe) are sent to the newly opened popup. If not then it maybe a setting in the IE that prevents this from happening.
Edit: To see the cookies in Fiddler go to the Inspectors tab, then to Headers. At Request headers (up) you'll see the cookies sent from server to browser. At Response headers (down) you'll see the cookies sent from browser to the server (they should be sent back to browser for subsequent requests).
Related
I can successfully login with the standalone mvc app without the iframe. But when I put the same app inside an iframe, I'm getting the Exception: Correlation failed exception.
When I tried with postman, I'm getting the following response:
I have also tried with different SameSiteMode configurations but to no avail. Is there any way or workaround to achieve this? Thanks.
I suspect the cookie is not sent by the browser.
You need to use HTTPS to get it to work together with samesite=none;Secure attributes added to the cookie. Otherwise the cookie will be blocked by the browser.
You can diagnose why a cookie was not accepted or used by going to the Chrome devtools and:
Open the Browser Developer Tools (F12)
Click on the network tab and reload the page
Click on the Cookies request
Select the Cookies tab
Then hover your mouse over the (i) to see the reasoning by the browser
we have an odd situation where a user logs into the site (Asp.Net), and upon logging out, it only directs us to the main page "https://newsite/default.aspx" however if we replace default with login, we are immediately logged back in. This happens only when we go through the public IP with associated DNS A record located on the F5. If we open the site on the IIS server via IP binding "https://ipaddress/default", I can login and logout and stay logged out, it works as expected. I have worked with F5 support and have tried multiple different configuration changes, and no dice, same behavior everytime. The newsite is set up identically in F5 to our current production site, and developers say the logout code is identical to current production so we are confused as to why this is happening. Persistence is set on the load balancer as well. Any help in the right direction would awesome.
A couple things I would suggest checking:
If you monitor the traffic with something like Fiddler and compare the results of login/logout with the F5 and without, do you see any difference? I would look for specific things like cookies being set or removed. I know ASP.NET uses specific cookies for sessions, so I would wonder if that cookie is not getting deleted properly on logout.
Once you log out of the site (when going through the F5), if you refresh the page, do you stay logged in (in this case, I could see where some kind of caching may send back the page even though you're logged out. If this is the case, you could have an F5 admin check to see if there's a Web Acceleration profile on the virtual server and remove it to see if that helps.
Looks like specific security cookie code was causing the issue of creating a duplicate cookie within ektron.
Following code was removed, and now log out is working properly via SSL through our F5.
Code removed:
Dim lSec As SecurityAPI.Cookie = New SecurityAPI.Cookie(Me, mServerEnvironment, mCOGUser.PeopleID)
lSec.SetCookie()
Internet explorer is not keeping my authentication cookie after one page redirect.
Here is the situation:
I have an ASP.NET 2.0 web application running on a shared iis7 hosting. The application uses forms authentication to handle login and user identity and writing a cookie (.ASPXFORMSAUTH) on the client machine for that purpose.
in IE (checked with version 8, 9), from some locations, the authentication cookie is not being kept after the first page. The observed behavior is:
User name and password are submitted in login form
User is succesfuly redirected to the first-after-login page (and fiddler shows that the .ASPXFORMSAUTH cookie exists)
After clicking another link or hitting F5 for refresh, the user is credirected to login, and the authentication cookie (according to fiddler) doesn't exist anymore.
at the refresh / click, the authentication cookie is missing in the request headers.
This doesn't happen in Chrome / FF, and even in IE, it seems to be dependent on the location from which I am connected.
also, locally (using the internal dev server in VS2008), all works fine and reflects fine in fiddler as well.
I am banging my head at it for a few days now. Thought it may be some kind of a strange firewall problem, but couldn't determine anything conclusive.
Ideas will be appreciated.
IE suffers from a weird bug - for some reasons, if there are non-alphanumeric characters in the domain's name, IE won't persist cookies... and hence you'll have no persistent session between different calls.
Check if your domain has non-alphanumeric characters in it, such as test_domain or test-domain or the likes. Unfortunately, I don't know any fixes for this short of aliasing the incriminated domain or accessing it directly via the IP. The reason you've got no problems locally is that you're pointing to http://localhost, which is fine. As soon as you deploy to a non IE compliant domain you'll witness the problem.
Happened to me and it took hours to find out why. Hope this helps. Another reason to kill IE with fire.
My solution has been a combination of other solutions:
IE not saving asp.net authentication token / cookies
http://connect.microsoft.com/VisualStudio/feedback/details/662275/asp-net-user-agent-sniffing-and-ie10-internet-explorer-10
upgrade to .NET 4.0 adding the tag ticketCompatibilityMode="Framework40" in the web.xml: http://msdn.microsoft.com/en-us/library/1d3t3c61.aspx
Note that the real final solution was the 3rd.
Last but not least: once I set this flag above I had to change the logout method in the code behind because the old one did not logout any more:
protected void LoginStatusLink_LoggedOut(object sender, EventArgs e) {
// remove the authenticatation cookies from the browser
FormsAuthentication.SignOut();
// force a new 'expired' auth cookie
HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName);
cookie.Expires = DateTime.Now.AddMonths(-1);
Response.Cookies.Add(cookie);
// delete roles cookie
Roles.DeleteCookie();
// clear and abandon session
Session.Clear();
Session.Abandon();
// this line just to leave (forget) the current page
this.Response.Redirect("~/");
}
1.try to create a persistant cookie
2.check your cookie settings for IE
Check the server's date. I had a situation where the server was 1 day behind the browser and so the authentication cookie essentially expired immediately. This affected IE, but not FF.
I know this has been asked and answered many times previously, believe me I've been through all of the posts looking for a solution before asking again.
If a user logs into a page, takes a copy of the URL, logs out then pastes the URL back into the browser, they can get access to the page they had previously visited very briefly before the browser redirects to the login page once more. During this brief window, if they are fast enough with the mouse and can click on a button or other control, they are somehow logged back into the site, no questions asked.
I've tried including the following code suggestion from another thread on the subject into each Page_Load event to avoid caching but no success.
private void ExpirePageCache()
{
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetExpires(DateTime.Now - new TimeSpan(1, 0, 0));
Response.Cache.SetLastModified(DateTime.Now);
Response.Cache.SetAllowResponseInBrowserHistory(false);
}
Code from logout.aspx is as follows:
protected void Page_Load(object sender, EventArgs e)
{
FormsAuthentication.SignOut();
HttpContext.Current.Session.Clear();
HttpContext.Current.Session.Abandon();
Response.Redirect("~/Account/Login.aspx");
}
Should I be using Server.Transfer() instead of Response.Redirect()?
I've read somewhere that I'm not allowed to clear the browser history programatically so am a bit stuck. Anyone have any clues please?
Yeah, that line of code is already included in the Page_Load event of the logout.aspx page. It's the first line of code that gets executed...
I suspect something else is up.
When you call response.redirect, none of the page content generated is sent to the client. ASP uses buffering, so as you generate your page, it's buffered until you get to the end, at which point that buffer is sent to the client. This allows you to make changes right up till the last moment, eg sending a redirect response. So that's not your issue.
Are you using output caching or setting the forms auth ticket to persistent? If the browser has a cached copy of the content, it will show that, rather than hit the server (as caching is designed to do). The minute you hit the server though, if the cookie is invalid, then the server should redirect you to somewhere to get a new ticket. if it's not doing that, then somehow it's finding a valid ticket.
You could use Fiddler to monitor the traffic. You can mimic a new browser session by sending request by hand using Fiddler and removing the session & ticket cookies.
Simon
What whould be the best way to prevent multiple users on a page?
For example if a user is at the page "Home.aspx", no other users should be allowed to go there.
I'm using asp.net on the server and the js-frameword jQuery on the client side.
The easy part is only allowing one user to access a page. You can for example store a session id in an application variable to keep track of who's on the page.
The hard part is to know when the user leaves the page. The HTTP protocol only handles requests, so the server only knows when a user enters the page. There is no concept of "being on" a page in the protocol.
You can use the onunload event in client code to catch when a user goes somewhere else, however this will not always work. If the user loses the internet connection, there is no way to communicate back to the server that the user leaves the page. If the browser or computer crashes, there will naturally be no onunload event.
You can keep requesting data from the server, by for example reloading an image on the page. That way the server can know if the user is still on the page at certain intervals. However, if the user loses the internet connection, the server will think that the user has left, while the user thinks that he/she is still on the page.
Another problem is browser history and cache. A user might leave the page, then go back to the page again. You have to make sure that the page is not cached, or the browser will just use the cached page and the server has no idea that the user thinks that he/she is on the page again.
Agreed with Guffa, you cannot be sure that the browser is already on the page or not, you can only check if the browser is already connected to that page or not.
You can do a sort of "ping", but its more a trick than a 100% working solution and it requires javascript enabled.
I didn't do it but I should look at XMLHTTPRequest and onreadystatechange to handle this :
1) On page load, the browser (client) initiate a XMLHTTPRequest with the web site (server) then wait for callback with the onreadystatechange event.
2) The web site receive the request and "mark" the page as "in use" with the current DateTime.Now.
3) Then the web site sends the response.
4) The onreadystatechange event get the response and the event code re-request the server to re-initiate the 2 after 1 min.
5) If another client request the page, the server check the DateTime mark : if the mark is greater than 1min ago, it means the client didnt respond to the request and may not be on the page again.
Not sure why you would want to do this because it flies in the face of web usability. You could do a locking mechanism on each page in server side code (write user name, page and time to a DB), which is freed up when they go to another page. You would then check on a the page load event to find out if anyone currently has that page locked. However, and this is a big however - have you considered what happens if somebody just shuts their browser down or walks off and leaves it on a page. You would need to seriously consider a timeout to free up locks too. That would need to be a back ground service, either in global.asax as global code or a separate process.
Maybe use static variables to hold the ip of the first user to access the page and then check whether other requests come from the same ip, otherwise display a "no access" page.
make sure you use lock it:
Object thisLock = new Object();
lock (thisLock)
{
// access static variables
}
You should also use "Session_End" method in global.asax to remove the ip address in case the user leaves your website without pressing the logout button