In my Winforms project, I can get a cookie of a site opened in IE by the following method :
InternetGetCookie("mysite.com", "mycookie", "something" , "something" )
As a new requirement coming, the site must be opened in Chrome. That means the method above doesn't work anymore.
After some research, I found out a solution to use Sqlite to read the cookies file stored in "Users\xx\AppData\Google\Chrome\User Data\Default\cookies", it works as expected. I can fetch the cookie by giving the name and URL.
BUT PROBLEM: The cookies file is not up-to-date and is updated 1-2 minutes laters. That means the cookies of the request shown in Chrome DevTool is not the same as in the cookies file.
Is there any way to fetch the cookie in Chrome from C# Winforms project similar to InternetGetCookie?
Hmm, there doesn't seem to be a chrome flag to flush this quicker so probably not going to be an easy option... You could maybe:
Grab it from memory (may be possible if you can search for the value somehow)
Write a Chrome extension which dumps it immediately
Use a headless browser instance to visit the site and send the cookie back instead
Related
I am working with provider hosted app using MVC with JQuery and have a requirement to show Provider Hosted App in an iframe in a SharePoint page to make it look like it is integrated in SharePoint. This application contains a report viewer(version 10.0.0.0) which is showing 'Asp.net session has expired or could not be found' when viewed in IE10 or higher. This app in a SharePoint page works fine when viewed in any other browser(Chrome, Mozilla) but not in IE.
Observations:
When the application is running directly in the Browser i.e.without using iframe, it is working fine.
When the Sharepoint page is viewed after opening the application directly in the browser i.e. in different tab, it works without any error.
But when viewed opening browser for the first time and no instances of the application are opened directly in the browser, it shows the error:
'Asp.net session has expired or could not be found'
Things already tried:
Increasing timeout for iframe as well as application in web.config file.
Setting report Viewer's KeepSessionAlive and AsyncRendering to false as well as true.
Reporting server timeout and all configurations.
Using sessionMode to InProc, SQLServer.
setting cookieeLess to true.
None of these are working for my scenario and I am struggling with this for a week. It seems like some registering problem at the first time and when the application is directly opened it gets registered and works. Any help will be highly appreciated.
P.S.: I have registered the report viewer in web.config file.
Thanks.
So guys finally i fixed my own issue. Thanks to the hint provided by mwwallace8 in the comments.
Problem: IE doesn't allow us to store third party session data in the form of cookies. This is because it gives lower level of trust to iframe pages, thus no session data for iframe will be stored in cookies. So when we submit the form and make a post call the server doesn't receive any session data in the request and thinks that it is the first request. This process generates a new Session ID and sends it back in the response. When the response comes back, the Session ID in the response and the is the new one and it thinks that the previous session expired.This generates the above problem.
Unlike when we open the application directly in the new tab, it takes it like first party and stores its session data in the form of cookies.
Because of this once we open the app in new tab directly, everything was working flawlessly.
Solution: IE needs P3P headers(Platform for Privacy Preference Project) to authenticate the session running in the iframe. This header will tell about what is the intent of the iframe session and what kind of data it will take from browser cookies. It is kind of swiping the Access card before entering in an IT company. So the question is how to generate this P3P header? The answer is here: Go to web.config file and add this code in Configuration tag
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="p3p" value="CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT""/>
</customHeaders>
</httpProtocol>
</system.webServer>
This will create a header certificate i.e. P3P header certificate which will authenticate the iframe session data to get stored in the browser cookies.
To know what these value actually means, go to This Link. You will find a whole lot of information about P3P headers in here.
Hope this might help someone.
Cheers..
I am using SqlMembershipProvider with asp.net and it works fine until I try to use iframes or frames.
When I login without them, I have no issues but if I wrap our website from our customer's site, and try to login, it just flashes and comes back to the original site with all the fields cleared.
I can duplicate this easily with our site on IE 8 and 9 but I have no issues with firefox or chrome.
Is there another way of accomplishing this or getting around it?
====== EDIT ======
Our clients are calling our 'portal' from their website and would like to integrate our portal into it seamlessly as if it is part of their site.
We thought we could accomplish this with an iframe wrapping our portal from their site but I am not having any luck with it working with the login, from what I have read it's a cross domain cookie problem(?).
Hope this helps clarify things some...
You can use FormsAuthentication.SetAuthCookie, and pass the initial credentials in the URL in encrypted way,
This question will strongly help you in internet explorer, other broesers ar OK,
Cookie blocked/not saved in IFRAME in Internet Explorer
I have tested with Chrome, Firefox, Opera (Will give a warning first time), it is working perfectly, no problem, but with IE, you need to see the question that I have provided.
Internet Explorer won't send cookies through IFRAMES unless you specify a P3P header.
The easiest way of doing this, is indicating a custom HTTP header in your Web.config:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="P3P" value='CP="CAO PSA OUR"'/>
This way you do not have to mess in your code with this stuff.
This HTTP header is called Compact P3P, and it should do the trick because I have been in the same situation than you before.
I am afraid that maybe the Safari browser it is a little bit trickier, since Safari won't send the cookies unless the user interacts with the IFRAME content as seen here: Iframe, cross-domain cookies, p3p policy, and safari with error: A required anti-forgery token was not supplied or was invalid . What would probably be not a big problem in your case.
Cheers.
If it's an option to install a subdomain in the DNS and add host headers to IIS, you could try to circumvent cross-domain security by setting up the subdomain to point at your site.
[top] example.com # customerIP => [iframe] portal.example.com # yourIP
Make sure the domains are shared by putting this JavaScript in your code:
document.domain = "example.com"
I am trying to disable cookies in my browser, and check that they are disabled in my .Net web app.
One on page I am storing a cookie like this:
HttpResponse response = HttpContext.Current.Response;
response.Cookies[cookieKey].Value = cookieValue.ToString();
On another page, I am retrieving the cookie like this:
cookieValue = request.Cookies[cookieKey].Value;
I am trying to disable cookies in my browser to make the above code fail but I can't seem to do that. I am using Internet Explorer 7 and 8. (I am working with these 2 browsers because IE7 is my company's current standard and IE8 is the future company standard).
In both of these browsers, I went to Internet Options > Privacy > Advanced, and checked override cookie handling, and blocked both 1st and 3rd party cookies (also deleted any existing cookies/history/temp files).
After doing that, I would expect the above code to not work, but it still works. I can still set and retrieve values from the cookie. Any idea why? I thought maybe the cookies aren't actually getting disabled, but if I go to hotmail.com, it gives me an error message saying "Your browser must allow cookies before you can use Windows Live ID." so I don't know.
Why do cookies still work when visiting my ASP.Net site?
Updated 5/14/2012:
It appears that the cookie settings in the privacy tab are ignored on local intranet sites (I don't know if that is normal or not) so this was giving me problems. I did however figure out a different way to disable cookies (which I needed for testing purposes), even for intranet sites. In IE8, I went to Tools > Developer Tools > Cache > Disable Cookies. This worked as expected and i could complete my testing. However I still have not found a solution for IE7.
Are you running the website locally?
I had a similar question I asked on SuperUser.
From what I can tell, Sparky was correct. localhost / 127.0.0.1 will always accept cookies regardless of your settings.
I am working on a site which is programmed in C# .net. It uses a CMS called ADX Studio (a decision which predates my time there) which provides a shonky form of URL Rewriting (as far as I can tell it works by assigning an aspx page as the default 404 handler in IIS).
I have an web form which lives at a rewritten URL. I edited it so that the html form's action points back to the rewritten URL:
var u = new Uri(Request.RawUrl.Split(new char[1] { ';' }).Last());
userAdminForm.Action = u.PathAndQuery;
(kind of ugly but works based on what Request.RawUrl is on these rewritten URLs).
The "pretty" URL is something like this:
http://www.site.com/admin/user/edit/
On my development box (Windows XP/ IIS 5) when I initially tried POSTing back to URLs like this I got a HTTP 405 error. I worked around this by adding a script mapping so Aspnet_isapi.dll handles all (*) requests. And everything works fine on my development machine.
I just pushed my changes to the live server (Windows Server 2003 R2 and IIS 6) and the post fails silently. The page refreshes but all of my logic (from within an IsPostBack path in the code) doesn't get hit. No errors are displayed, it just doesn't work.
If I remove my code setting the .Action of the form then the postback works but it is posting to the ugly URL corresponding to the physical location of the aspx file rather than my page.
Am I missing a simple way to make this work? I don't want to be switching URL rewriting method or anything as this is a large legacy site and is unfortunately pretty dependent on ADX Studio so I don't want to do anything that will break that.
[edited because somehow the code above lost its code highlighting]
The issue is that the page's <form> tag is referencing the "ugly" url as the action. You can resolve that by completely removing the action tag from the form. Browsers will, by default, postback to the same page, ie. the "pretty" url.
This article explains how to accomplish an "actionless" form (~ two thirds of the way down) http://msdn.microsoft.com/en-us/library/ms972974.aspx
It seems like the problem is the same as it was on IIS 5. I can get it to work by doing the following in the IIS Manager:
Right click on the relevant website and select "Properties"
Choose the "Home Directory" tab
Click "Configuration" down in the "Application settings"
Click "Insert" next to the "Wildcard application maps"
Browse to the location of aspnet_isapi.dll (in my case: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll )
Untick "Check that file exists"
Click "OK" back through the Russian doll of dialogs.
This is basically the same as the approach that I linked to in the question for IIS5. However, it's not optimal because IIS is running every request through asp (even static files). Which seems like it can only slow things down. I'd like to be able to specify that asp only needs invoking for HTTP POST requests at least.
The weird thing is that IIS5 gave a HTTP 405 error when POSTing to an extension without a registered ISAPI extension but IIS6 just fails silently. And the page is being run through IIS (I can debug with a breakpoint in the Page_Load function) but IsPostBack (and IsCrossPagePostBack) don't get correctly set. Could it be related to the view state? Is there any alternative to my solution described above?
I've come to what I think is an optimal solution for this problem. It turns out that ADXStudio CMS does use the default 404 rule to do some form of URL rewriting. This has a problem with http POST:
when IIS initially executes a custom
URL on a 404 error, it changes POST to
GET, even if the client does a POST
request.
(thanks to elite brains' blog post about setting up IIS6 and ASP.NET MVC).
Rather than creating my own HttpModule I decided instead to use Ionics Isapi Rewrite Filter to rewrite my URLs. I then set the 404 error handler in IIS to the default. And I created this IIRF.ini file to redirect all requests to the same format as the 404 handler produced:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /Default.aspx?404;http://%{HTTP_HOST}$1 [U,L]
And everything seems to work great. The advantage over my previous answer is that the rewrite code is low level and runs fast and the -f and -d switches mean that if a file actually exists it isn't re-written and so static files don't have the overhead of running through .net.
it's a really weird thing - i have a website that works perfectly in maxthon (internet explorer based browser). i started it in opera and found out that the data put in the Session dictionary on one site, is not available on the other... i mean i have Welcome.aspx, where when you click next the following code is executed:
Session["sessionData"] = sessionData;
Response.Redirect("~/Models.aspx");
while debugging i can see that in models.aspx Session in empty when executing in opera but everything is fine when executing in maxthon.
has anyone got any idea what can be wrong? because i'm clueless.. is this some opera preferences thing or is it something in code?
Edit: i checked Session.IsNewSession and while executing in maxthon isnewsession is set to false but in opera it's true. it seems that in opera when moving to a new page it somehow creates new session...
If your write the session on the first hit then you should do
Response.Redirect("nextpage.asp", false);
Otherwise it wont write the whole responsestream and the cookie might not have been written. You can instead choose to have cookiless sessions. But then your open to session hijacking.
ASP.NET session is stored by a key that is saved as a cookie in the browser. Check Opera to see if it is accepting cookies - it will need to in order for ASP.NET session to work properly.
Maybe you have cookies disabled in Opera. Session works (unless speciefies as cookieless in web.config) by storing an identifier in a cookie. If the brwoser does not allow the access, the server won't be able to locate the data