HI Guys I have the same issue and I am looking to solve it. Here is detail I have two web sites WebsiteA and WebSiteB (WebsiteB is not in my control, A type of black box for me.).
Both websites have seprate login page
I have alist of users,password of websiteB which I stored in database.
I want a kind of common login page. If user is login to websiteA and he want to go to websiteB, he dont have to enter the login and password information again.
I can not touch the code of websiteB. it's alredy deployed and runing.
In websiteB in login form they have a Userid textbox and Password textbox and and a login Button. This butoon is not a submit button. It has a click event which calls a function to validate the user. it's not a simple post.
WebsiteB has one webpage which has different frames. After login sucessfull. The pages doesnt go to any other page it remain on the same page but load the different frame.
According to my knowledge. I can use httpwebrequest class. But faceing the following problem.
Can not click the button.
Response.Redirect does not work.
It seems that WebsiteB is not storing any thing in cookies as cookies always return me a empty string
I really appriciate if anyone can help me on it.
How Can I use response.Redirect . As when I redirect it shows me the same login page.
Without knowing how login works to site B I could not say for sure, but at some point, I'm sure there is a post with login information. My best guess at a solution would be try to imitate what site B does on login. Use firebug and watch what gets sent, and what is returned. You'll have to mimic this behavior.
It may be something like:
POST credentials to site B for verification, returns verification result.
If verification is good, use token from verification result to redirect to site B.
Again, without knowledge of site B, I could not say, but whatever it does, it likely does using normal http, thus you can probably duplicate it. That said, site B may forbid you from logging in by only accepting logins from certain URLs.
As for using the HttpWebRequest, I think you'll find you're better off just having a hidden form which you submit from site A.
A HttpWebRequest will execute on the server of WebsiteA. Even if you execute the correct HttpWebRequest POST to WebsiteB, you won't be able to pass that session cookie to the user's browser without also immediately redirecting to WebsiteB.
There are other single-sign-on techniques you may want to investigate - the approach you have described will not work.
HI I figure out . We can create a string of XML and the converting the string into bytes and then use the normal write function of HttpWebrequest to Write the XML.
Related
I'm trying to automate testing of an ASP.NET (not MVC) website that uses Forms authentication.
I want to simulate what happens when a user submits a particular form; to do this, my code can POST to the corresponding URL - but that won't work unless my code can first log in as my test user.
I've tried posting to the LogOn page (supplying a suitable username and password), but this fails - and I think it fails because the website uses ASP.NET event validation. (If I use Fiddler to watch what's sent to and from the browser, there's an __EVENTVALIDATION hidden form item).
I'm guessing that I'll need to visit the login page once, get the __EVENTVALIDATION value, and include that when I post the username and password to the LogOn page?
Is that all I need to do, or is spoofing a Forms-authentication-based website a non-starter?
Well, in case it helps anyone else, I was able to get this working by issuing a GET request to the LogOn page, extracting the values of the __EVENTVALIDATION, __VIEWSTATE and __VIEWSTATEENCRYPTED hidden form fields from the returned HTML, and then POSTing those values back to the LogOn page along with the rest of my form values (user name and password).
I'm using a single instance of HttpClient throughout, so the ASP.NET session cookie is preserved between requests.
When I use:
FormsAuthentication.SignOut()
FormsAuthentication.RedirectToLoginPage()
The URL will show a ReturnUrl string, is this normal? Is there a way to prevent this?
I could just use a response.redirect, but was wondering why it shows the Return URL also.
Thanks
This is used when a user requests a secure url, they are then redirected back to this page after authenticating.
Take a look at this resource, very useful. Forms Authentication
As for removing this part of the URL, I don't think this is possible (but I haven't looked into it since it's a useful feature). You often get links to things such as news articles. You don't mind re-authenticating, but if you were to then just go to a random home page, that would be annoying, the desired action would be to have the site automatically redirect to the page you initially requested.
Edit: Another reason besides a direct link that you need to authenticate for, could be a scenario where you're reading a multi-page article, you click next page and the session has expired. You're taken back to the login page, authenticate and then return to the page you were reading. It would be undesirable to return to the homepage for you to search for that article again.
The FormsAuthentication.RedirectToLoginPage() documentation states that this method is for when you want to redirect the user to the login page, for example if a user logs out and wants to log back in as somebody else.
The returnurl is so that they are returned to the page they started on after a successful login.
It sounds like if you want them to go to the home page or some other url then you shouldn't use FormsAuthentication.RedirectToLoginPage() here. A response.redirect would be a fine alternative in my view.
To answer your question, it doesn't seem that there is a way to disable the ReturnUrl and still use FormsAuthentication.RedirectToLoginPage().
I am interested to detect the email client or website a new user of my site is redirected from. For instance, if he was redirected from Gmail.com (by clicking a link in one of his email there) I would like to track that.
If I need to manipulate the links leading to my website somehow I can do that.
I know there is a way to do that cause I have seen many sites and services doing it but I would like to find out how. I can track the user agent but this tells me nothing about the site or email client.
You must use QueryStrings for this purpose. For example the link that sends the user to your site must be like this www.yourwebsite.com/default.aspx?sender="googleMail"
You can get this using the code shown below when your default.aspx page loads
if(Request.QueryString["sender"]!=null)
{
string Sender=Request.QueryString["sender"].ToString();
}
You can set different Querystrings like
www.yourwebsite.com/default.aspx?sender="googleMail"
www.yourwebsite.com/default.aspx?sender="YahooMail"
www.yourwebsite.com/default.aspx?sender="googleAdsense"
There are methods to trace the users Browser, IP address etc. But to trace this you must adopt the above method.
My bank's website has 2 login pages for online banking. On the first page, I enter my username. If I don't enter a valid username, I get an error message, and do not get to the 2nd page. The 2nd page displays a picture based on my user name, and has me enter my password. If I manually type a URL to a page inside the site after entering my username but before entering my password, I am redirected back to the first login page.
Is there a good way to implement this in ASP.NET with Forms Authentication? I only get 1 loginUrl in my web.config.
I am fairly certain my bank uses Java.
I do not find this a good idea, because this way any attacker know if the user name is the correct, then its need to know the password.
Second reason is that is more complicate and you need to be sure that you do not forget something on the way to login.
Third reason is that is not the common way to login, so people did not have use to it.
If you like to make the same, you need 2 pages, in the first you ask the user name, then you search on your local database if this is a valid user, then you keep this user name on a variable that you send on the second page that is the actual login. On the second page you have a common asp.net login module, but you have hide the user name, and at the same time you have set it with the value from the previous page. And then the rest is up to you.
Hey I know the bank on this one. Well provided it's the same bank there is another page that the user has to visit if they are on a computer thats never accessed the login before. Once the enter the user name they visit a question answer page where the question is a random one they picked when they first signed up or at least when they thought up this cockeyed login page. Then they visit the password page.
You can implement this yourself if you are using the built in AspNetSqlMembershipProvider provider you can customize the built in login control and override the OnLoggingIn method. You can then do what ever checks you need on that login and move it to another page. On the next page you can override other methods the same way like: OnAuthenticate, and OnLoggedIn while still using the built in control (but customized) if needed. Then you can set the login page in your web.config to your first login page. You can see MSDN for other methods as well.
Now as already pointed out this is not ideal because it's not typical and most users will not understand what is going on or think it's flaky (just like i do about the bank). Not to mention you will need to do additional checks similar to how that bank is doing it to make sure everything is legit coming from the client. So in the end I wouldnt recomend it, it's to much hassle for the end user mainly.
My UI prototype requires me to show the sites login info all the time. Either I should show the usual username and password textbox or "you are logged in as". The last bit don't have to be secure, as it's only info to the user, nothing I will use server side. But the first part should send secure to the server.
It seems that I would have to use https for all pages on the site then. I would like to only use ssl for the things that are required to be secure.
One way is putting the login information into a https://../login.aspx and show it on my mainpage as an IFrame.
One disadvantage I can see is that the user won't know that https is being used, unless they read the IFrame src in the source code.
What do you think?
Are you using the built-in asp.net login controls or do you just use two textbox controls?
You could use your own form tag (not runat="server") with the action attribute set to "https://..." and just use two html input tags and a button to log on.
Again this wouldn't show the user that there credentials are secure when logging in.
Because of some recently discovered SSL attacks, it is always preferable to also put the logon form on a https:// page. Otherwise a hacked can intercept the http stream and change your form action from "https://..." to "http://..." and then sniff the credentials.
Another option would be to take advantage of the PostBackUrl property of the Button control.
You would need to create your own login LayoutTemplate to take advantage of this though. You would then be able to add the secure scheme to the current page URL, and set the PostBackUrl property of the submit button to that.
This would have a similar issues to your iFrame solution (the user wouldn't see the padlock symbols), however you would have the advantage that you wouldn't be using iFrames.
Another issue using an iFrame is the affects that they can have on the page:
They are a separate request, but can cause a block on the JavaScript PageLoad event firing.
The login form would only postback within the iFrame, so you'd need to refresh the parent page when the user is successfully logged in to remove it.
Additionally to that, errors would be returned in the iFrame, probably not leaving you much space for displaying the form as well, etc.
You've hit the major problems. You want the login, which needs to be on every page to use SSL, but you don't want the entire page to be SSL.
This is more of a business decision at this point than anything else. Would you rather your customers feel more secure about visiting your site, or do you want the login information present on every screen?
If you need to have both, you may need to also look at making your entire site SSL.