Portal Home > Knowledgebase > Articles Database > PHP - why am I getting "lol"?
PHP - why am I getting "lol"?
| Posted by FinalFrontier, 11-29-2011, 01:55 AM |
| I have this code:
When I use the wrong password, I still get "lol". Why is this?
|
| Posted by 8088, 11-29-2011, 02:08 AM |
| Use var_dump on both variables and find out.
By the way:and are the same.
|
| Posted by FinalFrontier, 11-29-2011, 02:28 AM |
| Thanks for the password advice.
|
| Posted by Matt R, 11-29-2011, 02:43 AM |
| Uh, I think I notice some more serious implications/issues here that need to be addressed such as the fact that you're storing plain text passwords in the database.
|
| Posted by MikeDVB, 11-29-2011, 02:44 AM |
| Nah, everybody does that - don't you know?
|
| Posted by Matt R, 11-29-2011, 02:44 AM |
| They may be the same, but one will take longer to process by the php engine.
^ That's the one you want.
|
| Posted by FinalFrontier, 11-29-2011, 03:01 AM |
| Cool, I have implemented a valid if() string that should be behaving correctly, right people?
|
| Posted by FinalFrontier, 11-29-2011, 03:08 AM |
| Ah, the problem was that the input name did not match what PHP was expecting. All problems now fixed. Thanks guys!
|
| Posted by Matt R, 11-29-2011, 03:21 AM |
| It may be working, but it's far from "fixed" if you're accepting user inputs in the form of passwords that are being stored in plain-text.
That's a huge security issue: Especially with a novice writing the code with little to no experience in application security.
I suggest looking into MD5 or SHA1 and learning how to implement them appropriately to help ensure the privacy and security of your user(s) data.
|
| Posted by FinalFrontier, 11-29-2011, 03:23 AM |
| Ok, now im going ****in crazy. The problem still exists. I've narrowed down the cause:
It doesn't work when I post the form to ../accesslay-by/, but it does work when I post it to ../accesslay-by/index.html...... What the hell!
I don't have this problem with other pages. Why this one??????!
|
| Posted by 8088, 11-29-2011, 03:28 AM |
| Considering your other topic, I'm getting the impression that your server is caching more than it should be.
Still, I wouldn't ignore Matt's advice if I were you (although I'd skip MD5 and start with SHA1).
|
| Posted by Matt R, 11-29-2011, 03:28 AM |
| Post a copy of the form itself using the code tags the EXACT way you have it.
Then post a copy of the PHP code itself, exactly as you have it.
|
| Posted by Matt R, 11-29-2011, 03:32 AM |
| I looked at that a few minutes ago and it seems unlikely. It seems more likely that their browser is caching more than it should be: The web server itself should never heavily cache the data unless explicitly directed to do so.
I've seen cases where Chrome or IE don't properly clear their cache and it causes a lot of frustration. I use Firefox to develop only for that reason: I've never had an issue with cache in using it.
Without the code, there's no real way to tell. Especially since we don't know what comes before or after the PHP that the OP posted up in the first post, so it could be a conflict or that if statement might be nested within another if statement that's failing.
There's just too many unknowns to give a solid answer so far.
|
| Posted by FinalFrontier, 11-29-2011, 03:42 AM |
| I'm just going to use the index.html solution for now. So, this thread is now definatly solved. I will fix it later for cosmetic reasons.
If a users browser does not unset session data correctly then this is the users fault for using a hopeless browser, such as IE.
When I design my sites, I target standards only. I don't have time to compensate for noobs that think Internet Explorer = the internet. Neither should you man. We are the computer enthusiasts, not them. Their in our domain. If their not happy, tell them good luck.
|
| Posted by Matt R, 11-29-2011, 03:45 AM |
| The browser doesn't unset session data... The server does.
The sessions are stored on the server itself, the browser just holds a cookie telling the server what session to look for. That's why relying on session data only and not cross checking other data (such as IP addresses) to assist in verifying a users proper identity is a bad idea.
Using IE wouldn't cause session data to unset or not unset: Your code would, and whether or not you're persisting the session_start() command from page to page.
|
| Posted by Matt R, 11-29-2011, 03:48 AM |
| On another note, I noticed that you're using the word "order" in some of your variable names alluding at the fact that you're building a system that can potentially accept payments.
If you're considering handling credit card information on any level, I suggest stopping now and hiring a proper developer.
I can see the code you're putting out, and it's not horrible by any means, but you're definitely not on par with security policies (as seen by the lack of hashing on passwords) to be able to properly handle and process credit card information.
Looking at your code, I could SQL inject my way through your pages without any issue using a number of methods. This isn't meant to scare you, or come off as rude, but you really need to consider your level of knowledge and whether or not you can build a system that's properly PCI compliant on your own.
|
| Posted by FinalFrontier, 11-29-2011, 03:52 AM |
| Yes, that would make sense about clearing it from the server.
|
Add to Favourites 
Print this Article
Also Read
