I'm having some problems with the module urlrewriter.net for ASP.NET.
I have a multilingual site with a URL like this;
~/home.aspx
To support languages I use this rewrite rule;
<rewrite url="~/de-DE/(.*)" to="~/$1"></rewrite>
Then in my code I get the de-DE part and set the right culture for the current thread. All of this works well.
After I login on the website I get a message "Hello, user x" to show i'm logged in. When navigating to another page, it doesn't display this message anymore and it seems like the page comes from the cache or something with the old (not logged in) data. Also, when I attach the debugger, nothing is executed for this request. If I visit the page like ~/home.aspx instead of ~/de-DE/home.aspx, does problem does not occur.
What could be the problem here?
Thanks
Nevermind!
I had accidently disabled the Check for newer pages in IE8 which caused all of the problems... I'm sorry for the useless question!
Related
I have a site which uses are a payment service that exists inside an iframe to take the customers credit card information.
In Chrome/Edge everything is working as expected, but in Safari, when the user is redirected back to the site via the iframe (the user is broken out of the iframe when returned to the site) the user is logged out and returned to the login screen.
This is seems to be something that has happened in the last few months but this may have just not be noticed. I am trying to wrap my head around the SameSite cookie information out there as this may be related.
Has anyone experienced anything like this and have any clue as to how to resolve?
It sounds very much like a SameSite problem.
A quick way to test that theory would be to set SameSite=None and test if it now works, then work back from there.
The fact that it works on Chrome but not Safari could suggest some quirk of Safari's implementation of SameSite.
I've found the following useful in learning about this:
https://web.dev/samesite-cookie-recipes/
https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/
https://andrewwburns.com/2020/08/05/dont-be-lax-about-your-samesite-cookies/
I have a personal website at http://deanattali.com/
A few days ago I shared my site on my feed and everything was ok. Now whenever I try to share any other page, Facebook does not parse it and simply ignores it.
I tried the Open Graph Object Debugger tool and it always returns "Error Linting URL An internal error occurred while linting the URL."
For example, try any of the following URLs:
http://deanattali.com/aboutme
http://deanattali.com/2015/03/12/beautiful-jekyll-how-to-build-a-site-in-minutes/
I even tried taking an HTML page from a similar site and copying the exact same HTML onto my site, and the parser worked for the other site but not for mine
Page on other site that works: http://keshinid.github.io/2015-02-26-flake-it-till-you-make-it/
Page on my site with identical HTML that doesn't work: http://deanattali.com/test
This is very frustrating, the error is very vague.
When I try to click on the link to see what the scraper sees on FB's debugger tool (https://developers.facebook.com/tools/debug/og/object/) it says "Document returned no data"
Another point worth mentioning is that this is a GitHub Pages website, with URL daattali.github.io and I have a CNAME to deanattali.com (I'm not sure if that matters at all)
I'm very lost, thank you
For anyone who will ever run into this problem in the future: a bandage fix seems to be to append ?fbrefresh=anystring to the URL. It looks like when there is a fbrefresh param in the query string, it works fine (doesn't matter what the value of the parameter is). Not sure what the underlying cause is, whether this is a bug or not.
As the title suggests, http://localhost/mywebapp is being automatically added to urls within my application.
User clicks an https hyperlink, but instead of browsing to
https://correcturl.something.com
it goes to http://localhost/mywebapp/https://correcturl.something.com
ie the localhost part is being automatically added. I'm sure there is an IIS setting that we are missing here.
It might not be IIS. If you're forming your URLs improperly, I'm pretty sure the browser will handle redirect to "current url" + "redirecting url".
example:
if you execute the following in a javascript console, you will not get redirected.
window.location.href = "/http://google.com";
Running that off stackoverflow page sends me to https://stackoverflow.com/http://google.com
which is incorrect.
I'm assuming that if you're testing urls in some dev environment locally, you'll produce a similar result against localhost. I can't give you a better answer without more information, however I would begin by looking for something in your app similar to what I described.
I have a page where i want the page to return a 404 response but remain on that page. Please don't ask why - the client wants it that way even after i discussed it with him.
I've got a .net page written in C# running under iis 8 and the app pool is configured to run under 4.0 integrated mode
When i set the statuscode to 404 in the page, it gets sent to the custom 404 error page that's set up for this site. After googling i found another post on SO mention using Response.TrySkipIisCustomErrors. From what i read it sounds like it's exactly what i need. I tried setting it to true and it had no effect in the behavior of the page - still get sent to the customer 404 error page that's setup in iis.
Anyone have any ideas why this isn't working?
Well - this is a first. First time I managed to find the answer before hitting the submit button :)
Found this IIS.net article:
http://www.iis.net/configreference/system.webserver/httperrors
which then lead me to find this:
http://msdn.microsoft.com/en-us/library/ms690576(v=vs.90).aspx
Scroll down to the part that explains what the options for existingResponse mean. I had mine set to Replace which means it ignores TrySkipIisCustomErrors completely. Changed it to Auto and it's working.
I posted a query for 301-redirect using ASP.NET 3.5 here:
Redirecting default.aspx to root virtual directory
Based on the replies I got there, I realized there might be a bug in ASP.NET's Request.RawUrl method which is unable to return the actual raw url (without /default.aspx) when being used in a sub-directory, i.e. the /default.aspx page is inside a subdirectory.
Can someone please shed some light on this possible bug?
Thanks,
Asif
i found a good explanation here
http://codeasp.net/blogs/vivek_iit/microsoft-net/873/301-redirect-from-default-aspx-to-site-root
Thanks
If you suspect this is a bug, then the place to go is Microsoft Connect, where you can report and discuss the bug directly with Microsoft.
Edit: I was able to reproduce the look per your comments.
I was unable to reproduce the infinite loop, however. I injected code into the Global.asax Application_BeginRequest handler of a web application and got the expected behavior of a single redirect.
There are other, and IMO much better, options for handling global redirect rules. On IIS7, I use the URL Rewrite module to configure rewrite rules in IIS. You can read more about it and download it here: http://www.iis.net/download/urlrewrite. The appeal of a solution such as this is that you can customize and update your rewrite rules without recompiling the application.
Edit: I was able to retrieve the raw URL without the default.aspx (after the redirect) by using instead:
Request.ServerVariables["CACHE_URL"]
It's worth a shot.
Have you looked at the IIS settings for your virtual directory? If there is a default document set to default.aspx then this will explain the infinite loop that you are experiencing. You are telling the website to redirect to the virtual directory without the "default.aspx" and IIS is detecting this on the next request and putting it back in ad infinitum.
Right click your virtual directory, select Properties and then the Documents tab. If default.aspx is in the list then that is what you will get. The Url of the request will be passed to the ASP.NET worker process as /folder/default.aspx rather than /folder/
This is not a bug. If IIS didn't do this, you would get a page not found error.
Sounds to me like you need to investigate URL rewriting: http://msdn.microsoft.com/en-us/library/ms972974.aspx