-
Posts
4,207 -
Joined
-
Last visited
-
Days Won
209
Posts posted by Jacques1
-
-
(though cross-version portability might still be an issue for some users).
All versions up to and including 5.5 have already reached end of life, so the password API should now be available in all common setups. If the server runs some kind of long-term-support version, there's a compatibility library which works exactly like the API but supports PHP versions down to 5.3.
And generally a fair point about scope - as long as you're considering users who are regular inhabitants of PHP Freaks, and not people who arrive here because of a specific Google search. This thread kept coming up in some of my searches, so I dropped in the advice that I had, and moved on.
Sure. I just have my doubts as to whether this is really helpful. Threads in a forum like this generally don't age well, because there's no proper mechanism for keeping them up to date or at least downvoting them (like on SO). You'll find the same problem – and much worse advice – in many other old topics, so trying to fix that seem futile. It's difficult enough to promote best practices in current threads.
Personally, I tell people to take all security-related advice with a grain of salt and just stay away from old threads. Security has never been a priority in the PHP community, and even the most basic concepts take a very long time until they're finally adopted. Posts from the last, say, 5 years may get it right, but anything before that is probably garbage.
-
The implementation is not secure.
First off, UUIDs are not meant for security purposes, and there's no guarantee whatsoever that they're difficult to guess. The only promise is that they're unique (with a reasonably high probability). Some UUID implementations do use secure random numbers, but others are simply time-based.
EIther way, using constant plaintext IDs as authenticators is the worst possible choice, because anybody who manages to obtain the IDs effectively gets unlimited access to the accounts. This is even worse than plaintext passwords, because passwords can at least be changed easily. If you're using the UUIDs for other purposes as well, they may also be leaked all over the place.
It also doesn't sound like you've even thought about a mechanism to terminate those persistent sessions or detect obvious abuse. What happens when the user hits the log-out button? What happens after 24h when the session should expire? Are you just hoping that the user will respect the cookie timeout? You understand that this can be completely ignored, right?
-
Guys. I understand that PHP people love to turn simple problems into fugly hacks with lots of bugs, but let's not be ridiculous. This is JSON. PHP knows JSON. Turning an array into a JSON document takes one function call. One. No loops, no string fumbling, no comma gymnastics. One function call. Writing this down is a matter of, say, 30 seconds including a quick check of the manual. Instead, you've already spent an hour banging your head against the wall. Even as a non-programmer, you should be able to see that this is not very smart.
-
Thanks for your reply but, I am totally not doing that.
Do you have a reason for that, or do you just like to waste your time on useless, buggy code? Because if it's the latter, it looks like you've already achieved your goal.
-
Looks like you're trying to generate JSON documents by hand. Don't do that. PHP is perfectly capable of doing that itself -- properly.
-
the first line on all my .php scripts that need the @_SESSION is '<?php session_start();'
PHP says otherwise, and I'm inclined to believe it rather than you.
The error message tells you exactly where the output started. Open that file and check the line. If you cannot see anything that would generate output, open the file in a hex editor. Maybe there are hidden characters like a byte order mark.
should I add 'ob_start();' as well?
No. As I already said, this is a hack, not an actual solution. The solution is to get rid of the output.
-
'headers already sent'
A quick Google search will tell you that this is one of the classical PHP mistakes.
The simple answer: You must not generate any output before calling session_start(). No HTML, not even blank space, nothing. Starting a session involves sending a cookie, but this isn't possible when you've already sent the HTTP response (and therefore the headers) to the client. So make sure the session_start() happens before that.
If the code worked before, my guess is that you lied about the “nothing has changed” and actually deactivated output buffering. Either way, the proper solution is to get rid of the premature output.
-
But for now this is just a college project [...]
If I got a dollar every time somebody says this, I would be a rich man.
I don't know what kind of college is this, but my professors actually checked my work and would have immediately rejected a submission which doesn't even survive the most basic tests. This is not just wrong. It shows a fundamental misunderstand of programming basics.
-
This script will delete anything the user asks for as long as the webserver has permissions to do so. Since a lot of web applications are both running under and owned by the same webserver account, this means a user can probably wipe your entire document root – and maybe more.
Do – not – trust – user – input. Do not let it anywhere near a file path, unless you've extensively validated the input and made sure it's harmless. Using GET requests to delete data is also a very bad idea, because this violates the HTTP protocol. GET is strictly for getting data (hence the name) and mustn't have any side effects. If you break that assumption, you quickly end up with accidental deletions due to page reloads, bookmarks etc. On top of that, your code is wide open to CSRF attacks, which means that more or less everybody can freely delete files on your server.
Learn the basics of HTTP, especially the meaning of GET and POST. Understand that the WWW is a public infrastructure with a lot of hostile activity. Even if you think your website is restricted to a handful of users, that's not actually the case. The script you've shown can be attacked by anybody who has read a few Wikipedia articles.
-
1
-
-
This may disappoint you, but none of us is a mind reader. We cannot identify the API you're using just by looking at the words “NULL bool(true)”, and we aren't able to deduce the inner workings of that API from this piece of (non-)information. Sure, it would make life a lot easier, but unfortunately, we're mere mortals.
Any halfway professional API is extensively documented (if yours isn't, look for an alternative). So the first step is to RTFM. Have you done that? The authentication procedure will involve credentials like an API key which you've received during the registration procedure and which has to be submitted in an API-specific way.
-
I didn't even get to the topic of security. The point is that the code is broken on every single level and one of the worst possible choices you could have made.
If you simply accepted that half of the features will never work and the other half will randomly crash, sure, you could do that. But you're obviously here to get this stuff fixed, and I'm telling you that's hopeless.
-
Well thanks for you time, but it didn`t help me at all.
His reply contained more useful information than any other resource you've learned/copypasted from so far. When you're completely new to a topic, it's a good idea to actually listen to those who know what they're talking about.
Whether you like to hear it or not, the code you've chosen is amateur crap which is at least 13 years out of date and hasn't been updated in the last 6 years. As soon as your hoster decides to update the PHP version (the 5.x branch has already reached the end of active support), the whole application will cease to function.
-
Create a string first. When that's done, you can take care of writing the string to a file.
I hope the columns aren't literally named “info1”, “info2”, “info3”?
-
Yes, it's common practice to spend all day long trying to come up with the most obscure solution to an imaginary problem.
However, your approach is not optimal. You should foo the bar into the baz, then bla the baz together the qux until the garply is ready.
-
2
-
-
I have no idea what you're trying to do there. First you want one record, then you want two records, and then you talk about loading 42,000 records all at once, which sounds rather insane.
Forget about SQL for now and give us the full picture. What do you want to do with what information? How is the resulting page supposed to look like?
-
You need to stop using relative paths all over the place. Not only is this the reason for this particular error. It's also unreliable, because any change of the internal architecture can break all paths at once.
Use absolute paths. Set up a configuration parameter which says where the documents are located. Then append the filename to get a full file path which is completely independent from the location of your script.
-
bro i m not using msql
You're talking to a signature, brah.
-
I'm tired of PHP Freaks.
Then go away. Your schtick of posting nonsense and then complaining about those who actually know what they're doing may have been funny for a while. But after 7 years, it's a rather lame routine.
Spend less time bitching and more time programming. Then you might actually get somewhere.
-
This thread is 9(!) years old. Why on earth would you dig it out?
phpass is even older and has long been superseded by the native Password Hash API. It even says that right on top of the phpass page.
Yes, some threads on this forum contain nonsense, especially the ones which are a decade old. Anybody with basic common sense knows that. And if the age isn't enough, the fact that the participants keep mixing up hashing/encryption and guessing/decyption should make it clear that they have no idea what they're talking about.
The rest of your advice is fine, but you should use that for current threads. There's still more than enough to do even today.
-
Because of operator precedence. Concatenation binds stronger than assignments, so PHP first builds the string
1 . '. ' . $myArray[$i] . '<br />';
and then "adds" that string to the counter, which discards everything but the leading 1.
Of course the real answer is: Don't do this. Precedence is tricky enough (parentheses can help here), but when the expressions also have side effects, even a seemingly simple piece of code can lead to all kinds of bugs. Don't try to save lines of code.
-
1
-
-
Do you not see the difference between actively telling the interpreter to perform macro substitution (like you did in dBASE) and expecting the interpreter to somehow magically figure out that a string is code (like you try with PHP)? Of course you can tell PHP to evaluate a string. But a) this requires you to actively call eval() and b) is so horrendously bad that you should forget that it exists.
If you can make dBASE perform substitution without using the ampersand operator, just by writing down a string and having the interpreter read your mind, you qualify for the One Million Dollar Paranormal Challenge.
-
If you repeat the mistake 10 more times, maybe a fairy will come along and change the rules of reality.
-
I said there are two options. Two. If you don't want the user to download the files separately, then use an archive (.zip, .tar.gz, whatever).
-
Read the reply. And, no, this is not fine. Some applications may be clever enough to recognize that your HTML table pretending to be a spreadsheet is actually an HTML table which should be imported, but that doesn't change the fact that the type declaration is nonsense and lead to errors at any time.
If you want a spreadsheet, then serve a spreadsheet. There are several libraries which can generate a valid file. But then again: Read the reply.
PHP MySQL validation problem
in MySQL Help
Posted
The ugly truth is that's it's practically impossible not to leak this information. Even if you show the same message, anybody can easily tell the difference between the two execution paths by comparing the response times. Since modern password hash algorithms are expensive by design, there will be noticable difference between an invalid e-mail address (which is instantly recognized) and an invalid password (which requires the server to compute the hash).
You can make such attacks harder by designing the system appropriately, but this requires a lot of work, experience and complexity.
A much better solution is to not use the e-mail address as a user identifier at all. Make the user choose a public name which doesn't have to be protected. This may be slightly less convenient, but the e-mail address will at least be somewhat protected.