I have a website on which a user can ask a question & also answer it. But if the user is not logged in & he/she try to answer question then they will be redirected to the login page.
Now, suppose there are 10 questions on website, then there will be 10 individual links where user can visit & answer every question BUT if they are not logged in then those urls will become 10 individual login urls because of redirect.
That is what happened to me, Google has indexed all the answer page urls as login urls. Please see the image.
Google search image
I don't want google to index those urls which are redirecting users to login page. How can we prevent their indexing?
I have 2 sites running on one instance of IIS 7.
A.site.com
B.site.com
These sites use forms authentication and there is one form for logging in on site A.
So if i try to access a restricted page on site B with URL
B.site.com/TEST/
i get redirected to
A.site.com/login.aspx?ReturnUrl=%2TEST%2f
I can then enter username and password to authenticate. So far so good.
After authentication I get redirected to
A.site.com/TEST/
instead of
B.site.com/TEST/.
Can anyone tell me how i can get around this problem and make IIS redirect me to the correct page?
Note: the authentication works fine - i can go to the page B.site.com/TEST/ and i am no longer redirected to the login page. So the problem is just redirecting to the wrong site or the value of ReturnUrl should not be a relative path.
A workaround might be to force the user to go back to the last page using JS instead. Not a great answer though i admit. I think this is an IIS bug since the documentation to set up forms authentication with different sub-domains does not mention this problem at all.
EDIT:
A better answer is change the loginUrl to include the domain.
loginUrl="https://A.site.com/Login.aspx?domain=B.site.com"
Then handle the redirect client side
I have in my main website root the file...
lib.php
So hackers keeps hitting my website with different IP addresses, different OS, different everything. The page is redirected to our 404 error page, and this 404 error page tracks visitors using standard visitor tracking analytics do allow us to see problems as they may arise.
Below is an example of the landing pages as shown in analytics by the hackers, except that I get about 200 hits per hour. Each link is a bit different as they are using a variable to set as a page url to goto.
mysite.com/lib.php?id=zh%2F78jQrm3qLoE53KZd2vBHtPFaYHTOvBijvL2NNWYE%3D
mysite.com/lib.php?id=WY%2FfNHaB2OBcAH0TcsAEPrmFy1uGMHgxmiWVqT2M6Wk%VD
mysite.com/lib.php?id=WY%2FfNHaB2OBcAH0TcsAEPrmFy1uGMHgxmiWVqJHGEWk%T%
mysite.com/lib.php?id=JY%2FfNHaB2OBcAH0TcsAEPrmFy1uGMHgxmiWVqT2MFGk%BD
I do not think I even need the file http://www.mysite.com/lib.php
Should I need it? When I visit mysite.com/lib.php it is redirected to my custom 404 page.
How can I stop this best? I am thinking by using .htaccess, but not sure the best setup?
This is most probably part of the Asprox botnet.
http://rebsnippets.blogspot.cz/asprox
Key thing is to change your password and stop using FTP protocol to access your privileged accounts.
I want to have an SSO for the following sites:
abc.com
def.com
I read this article which has a very basic example on how to setup an SSO with master/slave domain setup. While it was a very good read it leaves some questions unanswered.
abc.com will be the master site that issues the auth cookie.
Say the user is not logged in on any site. If the site is abc.com, all i have to do is check for the auth cookie, no problem. If the user is on def.com, the example in the article redirects to abc.com and returns the cookie content (if any) as a query parameter in yet another redirect. If the cookie has content the cookie will be stored on def.com.
Issues:
Every page reload on def.com triggers 2 redirects if local cookie doesn't exist.
When user logs out, both master and slave cookies have to be deleted and also propagate to any other slave sites.
When the user logs in, I must make sure a cookie is set both on master and slave sites.
I am especially worried about point 1. Is there a way to get around this?
I thought of having the authentication all in ajax, but then i would need a page reload if an auth cookie is returned from abc.com to def.com. Not a very pleasing solution.
Does anyone have a better architecture altogether?
EDIT
Writing this down helped me out to at least to some extent solve the problem. If cookies are set for master + all slave sites at login, point 1 is no longer an issue.
The question is still open for anyone that want's to improve the solution.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
We recently changed our login to use HTTPS, and we are experiencing issues with the login.
After the login, the user is redirected to an unencrypted (HTTP) page. When it reaches this page, the site checks if the user is logged in. It creates a new session and it appears that the user is not logged in, and thus our user is redirected to the login page. If the user logs in again, it will work.
The cookies are not set as https-only, but it seems like they don't work on http pages.
Does anyone know why this might be happening.
Edit:
I should have mentioned that the page that displays the login is on a different URL. (There is a login page from the machine running the tomcat instance, but the marketing site is on a wordpress install and uses a different domain).
I can't use the HTTP request first method to set the cookie, because the default Internet Explorer settings prevent the session cookie from being saved.
We have this problem with our app. We wanted a similar behavior of logging in via https, then redirecting to an http page.
The issue is that when Tomcat creates the session under https, it creates a secure cookie which can't be read in http. Note that this keeps getting filed as a bug in Tomcat and getting marked as "not a bug".
The solution we ended up is based on the message in this forum
http://forum.java.sun.com/thread.jspa?threadID=197150&start=0
Quoting from the forum thread: "One way to maintain the session in Tomcat, when the session cookie is getting created in SSL mode is to trick the browser by creating the non-secure cookie, when the secure cookie is getting created." This is accomplished via a filter that wraps the request and overrides request.getSession(). It's worked very well for us.
As a side note, redirecting from an https to http page will pop up a warning message in some versions of Internet Explorer "You are about to be redirected to a connection that is not secure." The only way we found to avoid this is to have the redirection be done with a meta refresh tag. Specifically, return a blank page from the original https request with a meta tag that refreshes to an http page. This avoids the warning message at the expense of making the code slightly more convoluted.
(I just noticed some of the advice here is a repeat of an earlier answer -- I apologize, but will post anyways since it is from direct experience).
Edit: I see in your comments you have two domains, which complicates the use of cookies. Can you use a proxy or web server such as Apache to present just one domain to the end users?
When using https tomcat establishes the jsessionid through a secure cookie, which cannot be transmitted through a non-secure connection. So when you fall back to http the session is lost.
The workaround (which I haven't done it myself) seems to be establishing the session through a http request before redirecting to https, and then setting a filter in the HttpRequestWrapper to plug into the nonsecure cookie.
I don't know much about this, but here are a couple of references:
http://forums.sun.com/thread.jspa?threadID=197150
http://tp.its.yale.edu/pipermail/cas/2006-March/002356.html
If you've verified the secure-only flag is off, and that the first cookie is being dropped correctly - I would guess that that there may be a path issue which is preventing the cookie from being presented again.