I have a web login page with the standard username password and login button controls. I would like to write a wrapper page that will render and auto fill the username and login form text boxes with a constant and force the onclick event for login button. Any suggestions how to accomplish this?
If you want this sort of functionality to decrease overall testing time you should also take a look at:
WatiN
or
IEUnit
If you are doing this as a production feature of your system you should look at implementing some sort of "Remember Me" option with browser-based cookies - you would likely never want such a feature that automatically authenticates any anonymous person to a user to your system out in the wild.
Depending on the specific form and how it is done, you can make a wrapper page that embeds the form inside an iFrame. You can then use JS to set the values inside the iFrame, and call the proper submit.
This would require testing and a bit of research, but i have seen it done.
NOTE: I also strongly caution against this due to the obvious security implications...but you know your situation/use better than we do.
This sounds like a terrible idea, security-wise. Don't do it.
If you're looking for a default login, as many sites show with a textboxes having "username" and "password", then they are attributes of the input tag.
If you want to automate a login for a demo purposes, as many FLOSS projects do, you could prefill with a combo of demo/demo (or similar), also as attributes of the input tag.
Related
I have a checkout process that lets users add items to cart, and they are able to go through the first step of the checkout before logging in. Once it gets to the part where they have to log in, I'd like to use a popup div for this rather than redirecting them to a login page so it doesn't feel like they're leaving the checkout process.
I'm not sure what the best way to implement this is though. In a perfect world, there would be a way to integrate this idea with the existing asp.net forms authentication and it would popup the div over the page you're already on before redirecting to the protected page. I don't 'think' that's possible though so wondering how else could I do this?
There are a variety of ways to skin this cat. If you are a bit more old school, you can use the AJAX bits and modal popup control extender. If you are not using the AJAX bits for anything else, I would not go this direction.
A newer approach would be something like a JQuery popup: http://www.formget.com/jquery-popup-form/
As JQuery is integrated with ASP.NET now, this is a much more modern approach.
The key here is making the call outside of the page context, which means JavaScript (AJAX is essentially JavaScript (and XML - as the name implies)). You then can bring the user's context into play without sending to a login page and then bringing them back to the cart checkout page.
There are other JavaScript libraries that can be used for the same purpose. I would google login popup JQuery (or other library) and you will likely find a full implementation somewhere and save yourself time inventing it.
Such a button is not rendered to the browser, so is there any way a malicious user would be able to trigger the action defined by the invisible button? e.g. with a JavaScript call to WebForm_DoPostBackWithOptions? Would ASP.NET accept a POST that appeared to be triggered by this button, even though it wasn't rendered?
Short answer yes.
It is always up to you (the developer) to ensure data received from user input (in this case a post) is valid. Having said that the asp.net framework will do a lot of verification for you, such as "suspicious looking post values".
It is possible to construct a post to a web endpoint, even if the page you display does not have a submit button.
Edit
This would be an example of security through obscurity and is generally not a best practice. Asp.Net "submit" buttons modify a hidden form field called __EVENTTARGET. The asp.net handlers will inspect this field when determining a button click "event". This value can be spoofed if the attacker knew the name of the event target.
Hiding/showing UI elements are good for improving the user experience, but you should always validate (on the server) user input before performing any business actions.
I don't believe it would, if it's not rendered it shouldn't accept the postback. .net uses hidden fields on the page to know which controls were on the page and can verify that during postback, so it knows what triggered the post back. if the control was not there to begin with it shouldn't accept it.
Yes, this is definitely possible. ASP.NET accepts all POST values for controls defined on the page, visible or not. Beware too of i.e. textfields that are set to "read-only". Don't use readonlyControl.Text after the post, and trust that it has the same value as it had the last time you set it.
Take a look at what is posted when you perform a submit with ASP.NET with i.e. Chrome Developer tools, Fiddler, etc, and you should be able to figure out how to add your own value to an "invisible" text field.
I know this has been asked several times, but I'm not happy with the answers so far.
Root problem is the way the browsers detect a "login form" to auto-fill the fields and decide if they should ask the user to save the info. It works fine if your form has just the basic login fields. If the same form has lots of other fields, the browser doesn't detect it as a login form.
The solutions I've seen say to use a separate non-ASPX form on your page. In my case all of my input fields are rather complex subclassed versions of ASPX controls, mostly to get stuff like a custom background image and nice handling of place-holder/watermark text and items of that nature. So trying to create a non-ASPX form is a lot more work since I can't use these controls on the form. I'd have to replicate them in standard HTML. I could do this, but would rather not. Plus it's more maintenance anytime I need to make a change.
Is there a better way? That lets me use all of the greatness that is ASP.NET.
My page has both a login area and a register area (name, email, DOB, etc). This is why the browsers are confused.
I seem to recall when I was writing a website for mobile browsers that there was some markup that could be used to tell the browser "this is a login name field, and this is a password field". If something like that was available, that would be perfect.
Maybe I could do something with an iframe? Like an ASPX page inside an ASPX page?
Despite the complexity of your code, any custom ASP.NET user controls will eventually render output as HTML and every browsers only speak HTML
What you 're looking for is how to write ASP.NET code that results HTML mark-up containing the simple attribute..
<input type="password" autocomplet="off" ...
So that all browser will able to recognize it's a form containing password field. It doesn't care what you do in code behind. Focus on the output.
on my webpage the user must select out of a radio button list/dropdown list of types of computer locations - i.e. network share, FTP, HTTP. I want a different popup to come up for each option in the list, and in that popup will be some input fields to enter the network path, FTP address/username/password, HTTP url etc. I'm guessing I can use AJAX for this?
Thanks
If you're going to use AJAX to accomplish this, a good starting point is to make it work without JavaScript enabled. This may sound counter-intuitive, but it will mean that you have to write all the code which renders and handles the forms based on the submitted information. If you do this in a modular way, it is then a simple matter to add in the AJAX functionality to request and submit the forms, and you will know that your solution degrades gracefully as well.
AJAX is one approach, though for simple forms it might be easier just to to render them all and hide them, then show the one you want the user to fill in.
I have a webservice that I need called, the result of which determines whether or not the user is allowed to submit the form.
Since this call is from javascript and not from code behind is it not reliable? Is there any way the user can get around the check -- by either going in with firebug and enabling the submit button, somehow making the method give a different result than was actually returned by the webservice, any other ways of being able to get around it?
Basically is there any way to call a webservice from javascript and have it's result determine whether or not a form can be submitted, and actually prevent the user from submitting the form at all? -- whether or not they have firebug, etc...
No, not possible.
Just to name a few possible reasons:
what if javascript is disabled?
what if the user submits the raw POST (using libcurl, for example)?
what if the browser, that the user is using interprets javascript in a way, different from your expectations (think, portable devices)?
Javascript validation is there for your users' convenience only and should never ever be used as a means of providing security.
You can never prevent the user from making an HTTP request that mimics submission of the form. While disabling the form via Javascript prevents submission for 95% of the users who both have Javascript enabled and don't want to circumvent your access control, anyone who understands HTTP can make the call and you are correct in showing that anyone with Firebug can do it in a matter of seconds.
Javascript isn't reliable for preventing anything. It shouldn't be seen as a security-wall, as it's too easily disassembled with things like firebug, iedevelopertoolbar, and many other browser toys.
Even if you could prevent them from submitting your form on your page, nothing stops them from creating a brand new form, on their own page, and point it toward the action of your form. Thus they're removing themselves from your "secure" environment, and instead chosing to play in their own.
Your suspicion is correct; the user can easily get around any possible Javascript validation.
You will need to use server-side code.
No, it is not reliable. Try disabling Javascript in your browser to see for yourself how easily you can get around it.
The user could simply disable javascript in their browser, or use something like NoScript. The best you could do is to try setting the form action itself in the return from the Ajax request, that way the form, as loaded, won't submit (except to itself). This will probably stop casual users but would be no impediment to a slightly more determined (or just bored and tech savvy) user. You will need to check on the server side whatever you do.
In general, no. You can make the form hard to submit without going through Javascript. Make the submit button not an actual submit button (<input type="submit">), but a pushbutton (<input type="button">) that submits the form in its onClick handler.
As everyone else said, no you can't do it. The only real solution is to have the web service return some dynamic value which the Javascript inserts in a hidden form input. Then whatever server-side code processes the form submission should reject the request if that value is not present.