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.
Related
Today, our B2B web application times out user sessions after 6 hours of inactivity. If a user's session times out, the user is redirected to the login page, and then redirected back to the original destination after login (via a "returnURL" querystring parameter sent to the login page).
This works great for regular HTTP GET requests. But what if a user is in the middle of a long data-entry operation and then goes home for the night? If the user tries to submit the form the next morning, their changes are lost.
Instead, I'd like to enable a similar workflow for forms like we currently have for GET requests: the user clicks "save", the user is forced to re-authenticate, and (if login succeeds) then the form would be submitted. Another alternative would be to force a re-login, but instead of submitting the form, simply drop the user on the original page so that the user could try again to save changes.
All the data we need to submit is on the client-- it's not like we're storing data in the session that would have been lost.
Is there an accepted pattern to handle this case? Should I use a window.open popup window and close it after successful login? Use a jquery dialog overlaid on the page? Something else?
I know that login UI is often treated specially by web apps to reduce cross-site scripting risk and for other security-related reasons, so wasn't sure if there was a well-known best practice for this use-case.
One way to handle this would be to periodically save drafts of the user's work, like StackOverflow does. For cost reasons that's not practical in our case-- for now we simply want to make saving-changes workflows resilient to session expiration.
We're using ASP.NET MVC on the back-end if it matters, and jQuery on the front end, but my question is really more about security and programming best practices that I'd expect to be platform-neutral.
It would depend on the amount of data being collected, but a possible solution could be to save the page state to the browser's local storage using either "localStorage" or "sessionStorage". "localStorage" and "sessionStorage" are properties of the web browser that are exposed in Javascript and are supported in most modern browsers (Chrome, Safari, Firefox, IE 9+). "localStorage" holds data indefinitely while "sessionStorage" holds data until the browser or current tab is closed.
It may be possible to store everything needed about the page, redirect the user to log in, and then reload the page using the stored data.
Before redirecting to login:
if (window.sessionStorage) {
window.sessionStorage.setItem("firstName", $("#firstNameField").text());
window.sessionStorage.setItem("lastName", $("#lastNameField").text());
}
After retunring from login:
if (window.sessionStorage) {
$("#firstName").text(sessionStorage.getItem("firstName"));
$("#lastName").text(sessionStorage.getItem("lastName"));
}
I have created a web page but i want to restrict only one instance of the page should be running at all times. The scenarios are given as below.
First time - User launches the page by URL and page loads.
User types URL again in another window and it should say that a page is already open OR refresh the existing page.
User closes the window and tries again - new fresh page will be loaded.
Additional Details : I have a database, user authentication.
Tried So Far : Set a flag in DB-->> This method how do i redirect the user back to the page which is already opened.
Any ideas to implement this.?
Thanks in Advance for your opinions and suggestions.
Perhaps you should use a cookie which expires when the user closes the browser. However, all browser instances may need to be closed.
First time, there is no cookie and http_referer does not contain the same domain. (set cookie now)
http_referer contains the same domain
cookie expires and go back to (1)
You should consider using cookies for this. Create a session-long cookie upon opening of the window and destroy it upon closing of the window. If a cookie already exists, you know the window is already open.
This of course relies on javascript and is easily got round. You can not use a server-side solution because it would be impossible to catch the closing of the browser window in order to clear the cookie.
Personally, I wouldn't try and restrict the opening of multiple windows but restrict the functionality available in each window. This approach would be much easier to control using a server-side approach, e.g. events fired in the window can be validated server-side.
On some websites, when you want to login, you need to enter a captcha as well. If I want to provide support for an user to enter a captcha into my application ( which will then log into the website ), how would I do this?
My problem is that the link to the captcha image is like this: example.com/captcha , and it serves a different image each time it's accesed.
My approach is like this:
request page
download image
show image to user
user inputs login information
application logs in
The thing is, if you download the image in order to show it to the user, you're actually receiving a different image than the one generated when the page was loaded, right? How can I get to the image that was generated when the page was loaded, so that when I show it to the user, it's the correct one?
The question is language agnostic.
I think your problem is about sessions, the session your app downloading the image and the session your app submiting the login form may not be the same session, then your captcha will never be correct, you should maitain the session between requests, normally is some cookie set by the website.
By design, most captcha will always give you a different image. No way to work around that fact.
The first thing to do, is to open up fiddler. That way you can see what the browser is doing so that it can autenticate & remain autenticated.
It usually comes down to a cookie being sent. So what you need to do is to hold the cookie on your client app, and have all the requests sent with that cookie. Different platforms provide features to do so, but I'm sure a quick search will show you how.
Remember to pay attention to all being exchanged in fiddler, you need to make sure your apps triggers the same. Besides cookies, pay attention to any hidden field a js might set on the form.
It sounds like you're trying to invent a captcha solution yourself. Have you considered using reCAPTCHA? It's free.
Can you be a bit more specific about your situation? From what you've said, I'm assuming the following:
You have a "client GUI app" that logs in to a third-party site. Is this a web-app, or a desktop/standalone application? In what language is it written?
Your app contacts the third party site and downloads the Captcha image. This image is then shown to the user.
The user enters the captcha phrase and submits it to your app. Your app then submits this phrase to the site for validation. This is where sessions come in. Assuming the remote site uses cookie-based session tracking, you will need to send the same cookie to the third-party server with this submission as you do when the image was downloaded (in the step above). This allows the server to match your submission to the correct image it sent. Precisely how you do this depends on what language you've written your app in and the precise structure of it all. Without more information, a more specific solution is impossible.
The image that's generated is also the image served to the user. Your 'main' html page doesn't/shouldn't generate the image, it only embeds it using the image tag.
You could pass a token of some kind with the captcha image, perhaps appended to the filename such as captcha-0ad719bef61bc6a0.jpg and the appended data could link into a temporary table in a database server side that has the correct answer. This would allow you to check things were ok without passing both the image and answer across to your application.
I'm not sure if I entirely understand this question, but wouldn't you simply store the captcha locally after requesting it from the server, and then embed the local image from the client application, while storing any necessary session captcha data that will allow the captcha to be validated on post, assuming the user input is correct?
If the problem is that the captcha changes everytime you request it, just request it only once.
Can you offer any more clarification if this wouldn't apply to you?
It depends from capcha to another captcha. Maybe you need to use sessions or cookies or some captcha image filename. Show the page with that captcha.
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.
I'm attempting to convert a home-grown login system to the standard asp.net login control included in .net. I want all communication on the website for a user not logged in to be in clear text, but lock everything in SSL once the user logs in - including the transmission of the username and password.
I had this working before by loading a second page - "loginaction.aspx" - with a https: prefix, then pulling out the username and password by looking for the proper textbox controls in Request.Form.Keys. Is there a way to do something similar using the .net login controls? I dont want to have a seperate login page, but rather include this control (within a loginview) on every page on the site.
You're not going to be able to do what you're talking about simply, because the postback (which is what the login control uses) is going to be whatever the page's security is (SSL or non-SSL).
Your best bet in this scenario is to use an IFRAME which contains an HTTPS (SSL) page that just contains thelogin control. You might have to redirect to another page after login that lets you jump out of the IFRAME.
Plan B would be to have a separate form on the page (outside your main FORM) which has the ACTION property point to another page where you handle the login. You will have to roll your your own login code to handle the forms authentication.
I was able to accomplish this by adding an OnClientClick event to the login button control and set it to the following javascript function.
`
function forceSSLSubmit()
{
var strAction = document.forms[0].action.toString();
if (strAction.toLowerCase().indexOf("http:") == 0) {
strAction = "https" + strAction.substring(4);
document.forms[0].action = strAction;
}
}
`
You aren't going to be able to have your site as non-SSL, with a login box on every page, and then submit the username and password via SSL.
The only way to really accomplish this is to use frames of some sort. This way your entire page could be non-SSL, but the login frame would have to be SSL.
The usual ways of doing this is to either lock down the entire site with SSL, don't worry about having the username and password SSL encrypted and go to SSL after they log in, or go the frame route I mentioned above.