5 ms·
Some more: - I wouldn't have any logic in the button click handler at all. Punt to a Login() procedure with parameters so it can be reused. I'm just generall
by breckinloggins 15y ago
Some more:
- I wouldn't have any logic in the button click handler at all. Punt to a Login() procedure with parameters so it can be reused. I'm just generally against having any logic in event handlers except in very simple instances
- Query string needs to be parameterized instead of built ad-hoc, but that may have been what you meant
- A catch would be nice. How will the maintainers ever know if there's a real problem?
- Lovely URL consisting of username and password in plain-text (although maybe that was a requirement). Also, if this were a larger site and it were still required to use WebForms, I'd come up with my own simple "router" logic so as not to hard code the URL schema everywhere in the code
Granted, some of these points may be a bit much for a programming exercise, but if I were applying for this job I would do these things with comments to demonstrate that I knew how to write maintainable code.
The REAL sad part? NOTHING about this surprises me.
- artmageddon 15y agoYeah, I touched upon the parameterized query with the SQL injection part but should've mentioned that more specifically. Good point about the catch... I missed it because I was shocked at everything else ;)
- tensafefrogs 15y agoNEVER EVER send a password as clear text. EVER. If that was a requirement, then the submitter should have said something.
- artmageddon 15y agoJust curious, how would you go about not sending out the password in cleartext? I understand WHY but I've never really figured out how to avoid doing so* *yeah, I realize I'm asking for trouble with this :)
- ceejayoz 15y agoPOST it to an HTTPS endpoint.
- whileonebegin 15y agoHow do we know the code isn't already posting to an HTTPS url?
- ceejayoz 15y agoWe don't. I'm simply answering the asked question - how does one securely transmit the user's password to a web application.