ASP:Login WTF
-
So, you want an elegant way to make a login page for your web application? No problem! Just drop the ASP:Login control tag on your ASPX page and implement the Login_Authenticate method in your code-behind file (does anybody else hate that term?) and you're done. Voila.
Now, the real test begins.
You have a user in the database, with a nice and secure SHA-1 hashed password. You build your project and navigate to the login page. You type in the username, and then the password. You hit enter, and it fails. No problem, you probably just mis-typed the password. Try again. Fail again. Type it out in Notepad to make sure you are typing it right. It's right. Try again, fail again. Hash the password by hand, check it against the hash in the database... yup it's right. Try it ONE MORE TIME. Nothing. Well, almost the last time. Someone else tries it and they move their mouse cursor over the "Login" button and click. It works. [b]HOLY MOTHER-LOVING DOUBLE-U TEE EFF!?!?!?!?[/b].
So what's the deal?
The enter key doesn't work in this situation. Period. It's not going to work. You can't make it work with the ASP:Login control without dozens of lines of flaky Javascript. Your boss is clamoring for the enter key to work. You're scouring the 'net to find a solution. The only solution? Ditch the ASP:Login control and implement it by hand, which you were trying to avoid in the first place. [b]So what is the purpose of this control's existance?[/b] To drive developers out of their damned minds.
-
I'm not sure about this since I haven't done ASP.NET in a year and a half, but wouldn't you be able to extend from ASP:Login and override it's login/pass-getting function to obtain it from Request.Form instead of using viewstate, or whatever it is it's doing? Or even override it's rendering to output whatever code it's doing on the form's onsubmit rather than on the submit button's onclick?
-
I actually have the same problem in IE with a login system.
If you type the password and hit enter, no matter how many times you do it, it will not work.
If you type the password and then click on the login button, it works.
This is on a PHP system. It works in FF and Opera fine, just IE.
Go figure.
-
[quote user="Vector"]I actually have the same problem in IE with a login system.
If you type the password and hit enter, no matter how many times you do it, it will not work.
If you type the password and then click on the login button, it works.
This is on a PHP system. It works in FF and Opera fine, just IE.
Go figure.
[/quote]Are you checking for the existance of $_POST['button_name']? PHP doesn't care about pressing enter or clicking the submit button, since the text/password fields get sent to the server either way. However, I do recall an issue where most browsers pass the submit button as a regular input field, but IE only sends it if you actually click the submit button; pressing enter in the form doesn't pass the submit button.
-
I'm really not sure what your problem is... I've been working with the ASP:Login control for going on a year now, without any problems resembling what you're describing. I can enter my user/pass and hit the enter key, and it logs me in no problem what-so-ever. I think your code must be b0rked...
-
This is management WTF, because ..... oh well no I just join you and bash IE.
-
[quote user="Dragnslcr"]
However, I do recall an issue where most browsers pass the submit button as a regular input field, but IE only sends it if you actually click the submit button; pressing enter in the form doesn't pass the submit button.[/quote]
QFT
But it's pretty retarded that the ASP:Login control doesn't take this into account. Usually, Microsoft stuff is coded to work very well together.
-
Could it be that you have another button somewhere on the page that is higher in the HTML hierachy. I've had problems before because when you press "ENTER" the first button in the form is the one that is pressed.
-
[quote user="djork"]
So, you want an elegant way to make a login page for your web application? No problem! Just drop the ASP:Login control tag on your ASPX page and implement the Login_Authenticate method in your code-behind file (does anybody else hate that term?) and you're done. Voila.
Now, the real test begins.
You have a user in the database, with a nice and secure SHA-1 hashed password. You build your project and navigate to the login page. You type in the username, and then the password. You hit enter, and it fails. No problem, you probably just mis-typed the password. Try again. Fail again. Type it out in Notepad to make sure you are typing it right. It's right. Try again, fail again. Hash the password by hand, check it against the hash in the database... yup it's right. Try it ONE MORE TIME. Nothing. Well, almost the last time. Someone else tries it and they move their mouse cursor over the "Login" button and click. It works. [b]HOLY MOTHER-LOVING DOUBLE-U TEE EFF!?!?!?!?[/b].
So what's the deal?
The enter key doesn't work in this situation. Period. It's not going to work. You can't make it work with the ASP:Login control without dozens of lines of flaky Javascript. Your boss is clamoring for the enter key to work. You're scouring the 'net to find a solution. The only solution? Ditch the ASP:Login control and implement it by hand, which you were trying to avoid in the first place. [b]So what is the purpose of this control's existance?[/b] To drive developers out of their damned minds.
[/quote]
I don't see any problems with any login control using ENTER on the keyboard. Can you be more specific why it doesn't work you? Why is it failing? Not posting back correctly? The event is not fired? The authenication fails for some reason? The password or username is messed up? You've provide no real information at all about the problems you are experiencing.
Can you provide us with a simple step-by-step example of how we can recreate the behavior you are seeing? Every time I've used this control it's worked fine for me with the ENTER key.
I suspect that you may be encountering a limitation/quirk of HTML in regards to form submitals and the enter key and how that is sent as a post/get, and in the true spirit of the internet you are of course blaming it all on Microsoft. Oops, sorry, I meant Micro$oft.
-
I've seen a similar problem on this very site - every time I tried to log in, it would throw me to the Search page, no matter how many times I tried. But if I actually clicked the "button", it would log me in fine...
-
[quote user="ender"]I've seen a similar problem on this very site - every time I tried to log in, it would throw me to the Search page, no matter how many times I tried. But if I actually clicked the "button", it would log me in fine...[/quote]
What browser are you using? For me, with both IE 6.0 and firefox, it logs me in just fine by pressing enter, i just tried it a few times in both.
-
I use Opera.
-
[quote user="ender"]I use Opera.[/quote]
Since community server is basically a collection of javascript hacks designed to reimplement HTTP on top of, er... HTTP, every browser has to be specially accomodated or it only halfway works. So far that amounts to IE6, IE7, and Firefox. (Beats the old version, which was IE6 only.)
-
still waiting for djork to give an example ....
-
I do have the same login problem on this site with firefox, but not with IE.
-
[quote user="djork"]
The enter key doesn't work in this situation. Period. It's not going to work. You can't make it work with the ASP:Login control without dozens of lines of flaky Javascript. Your boss is clamoring for the enter key to work. You're scouring the 'net to find a solution. The only solution? Ditch the ASP:Login control and implement it by hand, which you were trying to avoid in the first place. [b]So what is the purpose of this control's existance?[/b] To drive developers out of their damned minds.
[/quote]
Had this problem a while back - was baffled and frustrated by it for the longest time. In ASP.NET 2.0 the fix is easy - just set a "defaultbutton" attribute on the form tag, specifying the button that should fire it's click event when the user presses enter. Something like <form id="mainform" defaultbutton="btnLogin"....
-
@seizer said:
[quote user="djork"]
The enter key doesn't work in this situation. Period. It's not going to work. You can't make it work with the ASP:Login control without dozens of lines of flaky Javascript. Your boss is clamoring for the enter key to work. You're scouring the 'net to find a solution. The only solution? Ditch the ASP:Login control and implement it by hand, which you were trying to avoid in the first place. [b]So what is the purpose of this control's existance?[/b] To drive developers out of their damned minds.
Had this problem a while back - was baffled and frustrated by it for the longest time. In ASP.NET 2.0 the fix is easy - just set a "defaultbutton" attribute on the form tag, specifying the button that should fire it's click event when the user presses enter. Something like <form id="mainform" defaultbutton="btnLogin"....
[/quote]
I've taken that route now... but I had to ditch the ASP:Login control in the process. It was just a waste of time to even think that it would have saved any effort in the long run.
-
[quote user="Jeff S"]
I don't see any problems with any login control using ENTER on the keyboard. Can you be more specific why it doesn't work you? Why is it failing? Not posting back correctly? The event is not fired? The authenication fails for some reason? The password or username is messed up? You've provide no real information at all about the problems you are experiencing.
[/quote]
I'm not sure this is using ASP.NET Login controller, but it is made with some ASP & using Visual Studio. Either it's the problem with ASP or the devolper who made it is a retarded. The problem in it is fairly simple: It's using <input type="button"> instead of <input type="submit">
-
[quote user="Buzer"][quote user="Jeff S"]
I don't see any problems with any login control using ENTER on the keyboard. Can you be more specific why it doesn't work you? Why is it failing? Not posting back correctly? The event is not fired? The authenication fails for some reason? The password or username is messed up? You've provide no real information at all about the problems you are experiencing.
[/quote]
I'm not sure this is using ASP.NET Login controller, but it is made with some ASP & using Visual Studio. Either it's the problem with ASP or the devolper who made it is a retarded. The problem in it is fairly simple: It's using <input type="button"> instead of <input type="submit">
[/quote]That's an asp page, not asp.net, it has nothing to do with the original poster's rant.
-
[quote user="djork"][quote user="seizer"][quote user="djork"]
The enter key doesn't work in this situation. Period. It's not going to work. You can't make it work with the ASP:Login control without dozens of lines of flaky Javascript. Your boss is clamoring for the enter key to work. You're scouring the 'net to find a solution. The only solution? Ditch the ASP:Login control and implement it by hand, which you were trying to avoid in the first place. [b]So what is the purpose of this control's existance?[/b] To drive developers out of their damned minds.
[/quote]
Had this problem a while back - was baffled and frustrated by it for the longest time. In ASP.NET 2.0 the fix is easy - just set a "defaultbutton" attribute on the form tag, specifying the button that should fire it's click event when the user presses enter. Something like <form id="mainform" defaultbutton="btnLogin"....
[/quote]
I've taken that route now... but I had to ditch the ASP:Login control in the process. It was just a waste of time to even think that it would have saved any effort in the long run.[/quote]
So, in other words, as is often the case, you were doing things wrong and blaming ASP.NET on your problems.
-
@Jeff S said:
So, in other words, as is often the case, you were doing things wrong and blaming ASP.NET on your problems.
Could you be a little more offensive next time? With the asp:Login control you [b]CAN NOT[/b] use the DefaultButton property approach reliably, because the control has no way to access the button's unique ID. You can run your app and extract the "Log In" button's unique ID from the source sent to the browser (which in this instance is "ctl00$PageBody$LoginControl$LoginButton") but that is not guaranteed to stay the same. You would have to update this hard-coded string if you changed the Master Page. Do you have a solution for making the enter key work when using the asp:Login control?
-
[quote user="djork"][quote user="Jeff S"]
So, in other words, as is often the case, you were doing things wrong and blaming ASP.NET on your problems.
[/quote]
Could you be a little more offensive next time? With the asp:Login control you [b]CAN NOT[/b] use the DefaultButton property approach reliably, because the control has no way to access the button's unique ID. You can run your app and extract the "Log In" button's unique ID from the source sent to the browser (which in this instance is "ctl00$PageBody$LoginControl$LoginButton") but that is not guaranteed to stay the same. You would have to update this hard-coded string if you changed the Master Page. Do you have a solution for making the enter key work when using the asp:Login control?[/quote]
Again, I am still waiting for you to give me details on how to create an example where it doesn't work. ever time I've coded it up, it works fine, no need to do anything -- ENTER submits the form and it works fine. I can give you a step-by-step example if you like.
FYI -- there is a very easy way to get any controls unique ID -- the clientID property. just grab it on the prerender() event of the form and there you go. Set the default button property then and you are good to go. Again, it is all guesswork on my part on how to assist you with your problem since you have still provided absolutely no specific details about the problems you are encountering, you're just assuming that the "login control doesn't work!" and ranting about it without considering that perhaps you are doing something wrong.
It might help to go back and re-read your original post -- it's amazingly ignorant how you claimed that the problem must be asp.net's fault and that the control never works with an ENTER button....
-
@Jeff S said:
It might help to go back and re-read your original post -- it's amazingly ignorant how you claimed that the problem must be asp.net's fault and that the control never works with an ENTER button....
You're absolutely right. I was going overboard over the issue. As it turns out, [i]in my situation[/i] (where there is, as I see now, a <input type="image" runat="server"> tag in the Master Page somewhere) there is no way to make the asp:Login control work with the enter key. If it was standing alone with no other button-like inputs on the page it would fire the click event. But, still, you can't get the actual UniqueID/ClientID of the login button to set the DefaultButton for the form, so you're left implementing the login by hand.
Sorry. :) </thread>
-
[quote user="djork"] But, still, you can't get the actual UniqueID/ClientID of the login button to set the DefaultButton for the form, so you're left implementing the login by hand.
Sorry. :)
[/quote]
Why can't you?
-
@Jeff S said:
[quote user="djork"] But, still, you can't get the actual UniqueID/ClientID of the login button to set the DefaultButton for the form, so you're left implementing the login by hand.
Sorry. :)
Why can't you?
[/quote]Because the Login control has no method or property to access the login button and therefore no way to retrieve the unique ID. The only way to approximate the functionality is to view the HTML sent to the browser and put it in as a hard-coded string and hope that it doesn't change.
-
[quote user="djork"][quote user="Jeff S"]
So, in other words, as is often the case, you were doing things wrong and blaming ASP.NET on your problems.
[/quote]
Could you be a little more offensive next time? With the asp:Login
control you [b]CAN NOT[/b] use the DefaultButton property approach
reliably, because the control has no way to access the button's unique
ID. You can run your app and extract the "Log In" button's unique ID
from the source sent to the browser (which in this instance is
"ctl00$PageBody$LoginControl$LoginButton") but that is not guaranteed
to stay the same. You would have to update this hard-coded string if
you changed the Master Page. Do you have a solution for making the
enter key work when using the asp:Login control?[/quote]I
am going to have to agree with Jeff S here. I am by no means a .Net
programmer but the way you described your process for creating this
login, it seems as if you expected the IDE to just magically create the
page exactly how you wanted it to work. And why wouldn't you, it
does virtually everything for you. I can almost picture you the
way you described it getting frustrated again and again, because "it
should jsut work" and then blaming .Net for your oversight in how the
IDE constructed the page.Me and Jeff don't agree on some
things, but we do agree that tools can be part of the problem when
creating software if not used correctly. The tools are only as good as
the people using them, and using them in a correct manner.A simple google search says in fact you CAN do what you want ...
<font color="#000080" face="Tahoma" size="2">ASP.NET 2.0 introduces a wonderful work around for this. By simply specifying the "defaultbutton" property to the ID of the <asp:Button>, whose event you want to fire, your job is done.</font>
<font color="#000080" face="Tahoma" size="2">The defaultbutton property can be specified at the Form level in the form tag as well as at panel level in the <asp:panel> definition tag. The form level setting is overridden when specified at the panel level, for those controls that are inside the panel.</font>
So, it seems there IS a way to work it, the key is it's not a default button for the login control its a default for the form or page ...
-
[quote user="djork"][quote user="Jeff S"][quote user="djork"] But,
still, you can't get the actual UniqueID/ClientID of the login button
to set the DefaultButton for the form, so you're left implementing the
login by hand.Sorry. :)
[/quote]
Why can't you?
[/quote] Because the Login control has no method or property to access the login button and therefore no way to retrieve the unique ID. The only way to approximate the functionality is to view the HTML sent to the browser and put it in as a hard-coded string and hope that it doesn't change.[/quote]
And it shouldn't, the login control following GOOD programming OOD doesn't know what the PAGE'S default button is .. and rightly so.
-
any way you slice it, the limitation of potentially requiring some javacript to handle the enter button depending on how many things are on the page is a limitation of HTML ....
-
@djork said:
@Jeff S said:
@djork said:
But, still, you can't get the actual UniqueID/ClientID of the login button to set the DefaultButton for the form, so you're left implementing the login by hand.
Sorry. :)
Why can't you?
Because the Login control has no method or property to access the login button and therefore no way to retrieve the unique ID. The only way to approximate the functionality is to view the HTML sent to the browser and put it in as a hard-coded string and hope that it doesn't change.
Its amazing to me that so many people responded to this thread without a solution being given. Its pretty easy to do, and yes there is a way to access the login button within the Login control. Here it is:
this.Form.DefaultButton = ((Button)Login1.FindControl("LoginButton")).UniqueID;
easy peazy. no javascript, nothing flaky, no smoke or mirrors.
-
@jminkler said:
@djork said:
@Jeff S said:
@djork said:
Because the Login control has no method or property to access the login button and therefore no way to retrieve the unique ID. The only way to approximate the functionality is to view the HTML sent to the browser and put it in as a hard-coded string and hope that it doesn't change.But,
still, you can't get the actual UniqueID/ClientID of the login button
to set the DefaultButton for the form, so you're left implementing the
login by hand.Sorry. :)
Why can't you?
And it shouldn't, the login control following GOOD programming OOD doesn't know what the PAGE'S default button is .. and rightly so.
I don't think he meant the PAGE'S default button here but the log in button, that is actually PART of the login control.
-
@PSWorx said:
@jminkler said:
@djork said:
@Jeff S said:
@djork said:
Because the Login control has no method or property to access the login button and therefore no way to retrieve the unique ID. The only way to approximate the functionality is to view the HTML sent to the browser and put it in as a hard-coded string and hope that it doesn't change.But,
still, you can't get the actual UniqueID/ClientID of the login button
to set the DefaultButton for the form, so you're left implementing the
login by hand.Sorry. :)
Why can't you?
And it shouldn't, the login control following GOOD programming OOD doesn't know what the PAGE'S default button is .. and rightly so.
I don't think he meant the PAGE'S default button here but the log in button, that is actually PART of the login control.
Yeah dude, I realize that. His problem is that when someone types their name and password and hit "enter" the default button of the page is set to an ImageButton on the page rather than the Login Button. He wants the "enter" key to trigger the Login button rather than some random ImageButton somewhere on the page. Using the forms defaultpage property you can easily set the default control to be triggered when "enter" is pressed.
Here is the breakdown of the code I submitted
this.Form.DefaultButton = ((Button)Login1.FindControl("LoginButton")).UniqueID;
Login1 is the name of the login control. We use the FindControl method associated with the login control to find the login button named "LoginButton" which is child control of the LoginControl. We then cast the found control to a Button so that we can use the associated UniqueID property to get the ID of the control which is assigned to the pages default button.
Regardless as to whether I am confused on what he is trying to do he stated that it is impossible to get the control ID of a login button within a Login control. That couldn't be further from the truth, its very easy to do.
-
UniqueID comes from Control so you don't even need to cast it to Button.
-
Thanks ChimRichalds for solving the problem.
-
@Jeff S said:
any way you slice it, the limitation of potentially requiring some javacript to handle the enter button depending on how many things are on the page is a limitation of HTML ....
The real limitation here is the one ASP.NET imposes regarding <form runat="server">. Standard, well-written HTML can make use of many forms on the same page, each containing only related fields. ASP.NET's implementation, on the other hand, requires that all controls that perform a postback be contained in a single form which encompasses all the server-side controls you create. This is so that the server can bind all the submitted data back to the original controls and fire the appropriate events.
This all works relatively well, but the markup sent to the client is extremely ugly. I would not call this a "limitation of HTML" but perhaps a "limitation on this form of abuse of HTML." ASP.NET is an attempt to make HTML do things that it was never designed to do. HTML has the mechanisms to handle form submissions simply and effectively, but those mechanisms don't mesh well with ASP.NET.
A webpage might have a form for a search, a form for a login, and possibly several other forms. Standard HTML would place each of those in a separate form so only data pertinent to your submission would be sent. ASP.NET would place all of them in the same form so a single postback could read data from all controls on the page. The standard HTML approach gives the browser a hint: pressing enter pertains to the form with the focus. ASP.NET doesn't have that hint, so the browser has to make the decision, and it decides the first submission control in the form is the appropriate one. It can use javascript to override the default behavior, and it will do that transparently to implement the defaultbutton attribute.
-
extend from ASP:Login and override it's login/pass-getting :blah blah: obtain it from Request.Form instead of using viewstate, or :blah blah: override it's rendering to output :blah blah: on the form's onsubmit rather than :blah blah: the submit button's onclick?
Have you considered PHP? Python? BASH? C? DIY Gall Bladder removal? Surely you can't seriously stick that many objects together with blue-tack, finger crossing, cursing and JS to pursuade an overly generic base type to do your bidding, day in, day out, without loosing your mind.
Create an Auth class. Give it a name. Give it knowledge to create the HTML form. Allow it to swallow a whole post, extracting its own args from the sweet jelly centre. Allow it to answer questions - is this user logged in? What groups are they in?If you demand code reuse, then reuse it - as an Auth class. If you need the info in other places in your app, make it a singleton.
Sleep soundly in the knowledge that you understand every nuonce of your creation.
-
@Olius said:
Why reinvent something that works fine for so many people?extend from ASP:Login and override it's login/pass-getting :blah blah: obtain it from Request.Form instead of using viewstate, or :blah blah: override it's rendering to output :blah blah: on the form's onsubmit rather than :blah blah: the submit button's onclick?
Have you considered PHP? Python? BASH? C? DIY Gall Bladder removal? Surely you can't seriously stick that many objects together with blue-tack, finger crossing, cursing and JS to pursuade an overly generic base type to do your bidding, day in, day out, without loosing your mind.
Create an Auth class. Give it a name. Give it knowledge to create the HTML form. Allow it to swallow a whole post, extracting its own args from the sweet jelly centre. Allow it to answer questions - is this user logged in? What groups are they in?If you demand code reuse, then reuse it - as an Auth class. If you need the info in other places in your app, make it a singleton.
Sleep soundly in the knowledge that you understand every nuonce of your creation.
-
@Olius said:
extend from ASP:Login and override it's login/pass-getting :blah blah: obtain it from Request.Form instead of using viewstate, or :blah blah: override it's rendering to output :blah blah: on the form's onsubmit rather than :blah blah: the submit button's onclick?
Have you considered PHP? Python? BASH? C? DIY Gall Bladder removal? Surely you can't seriously stick that many objects together with blue-tack, finger crossing, cursing and JS to pursuade an overly generic base type to do your bidding, day in, day out, without loosing your mind.
Yes, yes, yes, yes, no. This might be a surprise for you, but there are lots of people out there that actually work with both MS and Linux tech. So .NET has Request.Form and PHP has $_POST. .NET sticks objects together, PHP sticks arrays pretending to be objects together. What's the difference?
@Olius said:
Create an Auth class. Give it a name. Give it knowledge to create the HTML form. Allow it to swallow a whole post, extracting its own args from the sweet jelly centre. Allow it to answer questions - is this user logged in? What groups are they in?
If you demand code reuse, then reuse it - as an Auth class. If you need the info in other places in your app, make it a singleton.
So what would you do if you want it to render a different form? Or a different form of authentication, say, through $SERVER['PHP_AUTH_USER'], rather than $_POST? Would you reimplement the entire class, or perhaps, maybe, just maybe, extend from your Auth class and override it's login/pass-getting blah blah and override it's rendering to output blah blah? Wouldn't it also be nice if the base Auth class already came implemented for you?
Whoops, now we're sticking classes together again! Heresy! Not like the whole point of classes or anything, no sir!
Sleep soundly in the knowledge that you understand every nuonce of your creation.
I do. Today I'll sleep even better having fed my ego on the thought that my application has less simplistic nuances than yours, and yet I still understand them.
-
<FONT face="Times New Roman" size=3>Chances are you have another button on your page which is the default button for the page.</FONT>
<FONT face="Times New Roman" size=3>You can change this programmatically:</FONT>
<FONT size=2>Page.Form.DefaultButton = YourSubmitButton.UniqueID</FONT>
<FONT size=2>Of course this will fsck up default 'enter' behaviour for anything else on your page which may need it :)</FONT>
<FONT size=2>HTH
</FONT>
