I've encountered a problem where after a user logs in the application, he gets redirected to the home page instead of the requested resource. I've checked the web.xml and found no misconfiguration.
Also searched the codebase for redirects/forwards, but found none.
The strange thing is that the url always has a hash mark in the middle. It's definetely not a url fragment, because the servlet's name is after it. I have no idea how it gets there, but I cannot reach the servlets without it. Google only gave me stuff about fragments.
I'm using websphere, which I'm fairly new to. Could it cause this?
Any thoughts on the issue?
Thanks for the response!
I still have no idea why that hash mark is in the middle of the URL, but this solved the problem:
https://wiki.jasig.org/display/CASUM/Preserving+URL+anchor+fragments+on+login+form+submission
Have to handle these stuff client side (in this case JavaScript)
Related
This is either a problem that Google is inflicting upon me, or a problem I am inflicting upon myself. I'm not totally sure.
When I first created my website a couple years ago, it followed a path similar to: http://www.mywebsite.abc123.com
Now, after a change in hosting services, I changed my domain to simply: https://www.mywebsite.com
I also added an SSL certifcate at the time for what it's worth. And it's been almost six months. I have all the variations (past and present) of my website registered and verified with Google's search console, but I can see no reason why the http://www.mywebsite.abc123.com link is getting indexed over the https://www.mywebsite.com link. I actually just assumed that http://www.mywebsite.abc123.com wouldn't even work anymore.
I've read about 301 redirects and it looks like something like that would solve my problem, but upon trying to implement it, I was confronted with nothing but a "Too many redirects" error.
Long story short, Google won't index my newer better URL.
But Yahoo and Bing will.
301 redirects have to be set up in the old domain so that it will point to the new one. If you still have access to that domain, you can add the redirects via .htaccess or in the admin panel.
I initially asked this question, which shows that I see MVC errors of missing POST values. I was unable to reproduce - I still can't reproduce it on demand, but I did get the error myself on IE11, and I got a clue...
I have an application in IIS7.5 running with Basic authentication only. I look in Fiddler, and normally all transactions have Authorization: Basic xxxxx as expected. The body contains POST values as expected, and Content-Length is correct.
When I experienced this problem, I found that every single request (GETs and POSTs, including static content) was now showing Authorization: Negotiate xxxxx in Fiddler, with an empty body and zero Content-Length, even when I submitted a POST object via jQuery AJAX, and IE's dev tools shows the real POST body (which of course means IE is lying - not the first time). It gets a 401 response, and then a new request occurs with Basic, but also with an empty POST body, which means ASP.NET throws an error about missing parameter values.
Other web applications on the same top-level domain do use Windows authentication instead of Basic, and my suspicion is that the user goes to one of these sites, and IE becomes confused and thinks that my application should use Windows authentication as well - but I can't reproduce that every time. I have reproduced it twice, but out of a dozen or so times of doing the same thing over and over, so I'm not finding a way to make it reproduce every time.
I don't know why the POST body would get emptied, even if it does switch over and try to do WinAuth instead of basic - but that's when the problem occurs, so I'm sure it's related.
Any ideas on how to prevent IE from getting confused and using Negotiate, or at least how to detect and gracefully handle this on the server? I've only seen it in IE, but I can't be sure it's IE-only.
Here's what a normal POST looks like:
Then after the problem starts occurring, the exact same POST looks like:
EDIT
Here's an interesting edit - I just saw a new symptom. This time, all GET requests are coming in with no Authorization header at all, and the response comes back with a 401 for basic, and the GET is re-done properly with basic. But the POSTs are going through normally, with basic on the first try. I don't know what started this happening, but it's a similar symptom of the same problem.
I've seen a lot of different topics about this but none of the have solved my problem. I can't even reach my mvc site. I get this error before i even get to my loginpage. It seems that there is some problems with the cookies that it saves the cookies for to long but i have set it to not save the cookies at all now. I have changed the properties in my .csproj file that i found one topic about but i still have the same error. I have deleted all the cookies in this mapp "AppData\Roaming\Microsoft\Windows\Cookies" in hope to delete the cookie that is to long but this didn't solve my problem.
I'm starting to think that maybe this have nothing to do with the cookies? Plz help!
I'm starting to think that maybe this have nothing to do with the cookies?
That is correct, this has nothing to do with cookies. As per MSDN, 404.15 indicates the query string is longer than IIS is configured to accept.
As for why your query string is too long, I can only guess. But something in your application is adding too much information to the URL.
We have realized that this URL http://Keyword:redacted#example.com/ redirects to http://example.com/ when copied and pasted into the browser's address bar.
As far as I understand this might be used in some ftp connections but we have no such use on our website. We are suspecting that we are targeted by an attack and have been warned by Google that we are passing PII (mostly email addresses) in our URL requests to their Google Adsense network. We have not been able to find the source, but we have been warned that the violation is in the form of http://Keyword:redacted#example.com/
How can we stop this from happening?
What URL redirect method we can use to not accept this and return an error message?
FYI I experienced a similar issue for a client website and followed up with Adsense support. The matter was escalated to a specialist team who investigated and determined that flagged violations with the format http://Keyword:redacted#example.com/ will be considered false positives. I'm not sure if this applies to all publishers or was specific to our case, but it might be worth following up with Adsense support.
There is nothing you can do. This is handled entirely by your browser long before it even thinks about "talking" to your server.
That's a strange URL for people to copy/paste into the browser's address bar unless they have been told/trained to do so. Your best bet is to tell them to STOP IT! :-)
I suppose you could look at the HTTP Authorization Headers and report an error if they come in populated... (This would $_SERVER['PHP_AUTH_USER'] in PHP.) I've never looked at these values when the header doesn't request them, so I'm not sure if it would work or not...
The syntax http://abc:def#something.com means you're sending userid='abc', password='def' as basic authentication parameters. Your browser will pull out the userid & password and send them along as authentication information, leaving the url without them.
As Peter Bowers mentioned, you could check the authorization headers and see if they're coming in that way, but you can't stop others from doing it if they want. If it happens a lot then I'd suspect that somewhere there's a web form asking users to enter their user/password and it's getting encoded that way. One way to sleuth it out would be to see if you can identify someone by the userid specified.
Having Keyword:redacted sounds odd. It's possible Google Adsense changed the values to avoid including confidential info.
I have created a Web application which runs on Apache using TWebModule. I have gotten a little "liberal" with the use of SendRedirect. In one case I found I was calling SendRedirect and following it up with another SendRedirect call - all in the same method handler. On my Test box, it would always redirect to the url of the first SendRedirect. But on my production box, I discovered (much to my chagrin) that it was redirecting the browser to the url of the 2nd redirect.
I know the "Real" answer is that I should not be calling multiple SendRedirects. But aside from that, does anyone have an explanation why in one environment it goes to the first SendRedirect while on another it goes to the 2nd?
Check Location: header you get. You probably have different rewrite rules, or some other appache configuration options set.