I would say the performance are equivalent, with maybe some overhead if there is some heavy thread spawning. I'll run some benchmarks at some point.
One of the biggest advantages is the fact this is not multi-threading, so context switches can only happen at precise points (yield from). This makes it easier to reason about the code.
I used that at some point, but I tend to prefer the explicit yield of asyncio to the implicit context change of greenlets. (This blog post is a good explanation of that: https://glyph.twistedmatrix.com/2014/02/unyielding.html)
I'm an old Civilization fan, and recently I have enjoyed playing Paradox's game (Crusader Kings, Europa Universalis and Victoria). They touch the same spot that Civ5 wasn't able to touch.
Seconding this. The latest Europa Universalis game is eating all my time while I conquer South-East Asia one nation at a time. Imagine a Civ game with twice the depth and ten times the run time.
Except the problem most people actually want to solve is not "convert newlines to <br>", it is "convert some text to html", and this function may lead to think that it does that, when it only does a tiny fraction of that. And that's how injections are born.
I've never once had the impression that nl2br did anything more than make whitespace significant in an HTML document. Even during my first days of using PHP... I don't think there's anything in the documentation or even trivially basic experimentation that could reasonably lead someone to believe that.
Plus the actual HTML-escaping tools (htmlspecialchars, htmlentities) do not make whitespace significant.
Though these days, you might arguably be better off with "white-space: pre-line" in CSS instead.
It does less than making HTML whitespace-significant. It's unsuitable for use on HTML markup, because newlines in <script>, inside tags, attributes, comments, etc. should not be changed.
It's only safe and reliable as a part of nl2br(htmlspecialchars()) combo, so a function that does both could have been a better idea.
What is being suggested is that the plaintext may contain a random html tag (Perhaps if supplied by a user, or perhaps because that tag is meant to be displayed as plaintext as well. The reason doesn't rally matter, "tags" in any situation are still valid plaintext). By passing text to something that replaces new lines with br the implication is that it is now safe to drop into HTML -- however now that tag from before can take effect (particularly bad if its a script tag). Thus, this function doesn't make sense unless it is at least also coupled with HTML escaping.
It's implied because basically the only context under which <br>'s are used is when appearing in HTML. If someone is taking text, converting the newlines to <br>'s, then there's a 99.9% chance that the next step is that that text is going to be placed in a larger HTML document. Unless of course I'm forgetting some alternative use of <br>'s.
I agree the function does exactly what it says it will do. And if this was a private function used by something like text2html internally, then maybe it might be a fine function. However, as a public function, the argument is that it inspires bad programming practices, since again, it is almost certainly being used as a primitive form of "sanitation" or "conversion" before displaying plaintext in a larger HTML document.
I think if you could come up with an example of how this would be used NOT as an immediate precursor to dropping into HTML I could be convinced otherwise (and saying it is used after the other tags go through a sanitation process is a poor response, since it means this function must always follow the other one -- further proving its uselessness as a standalone function).
I have never, ever seen nl2br referred to as making anything secure or safe. It just converts new lines to <br />s. That's what the manual says it does. That's what tutorials say it does. That's what the function name very obviously shows.
I think map() from Python should be removed. Its name implies to a new learner that it will draw a map, but it actually does nothing to that effect at all! No, it maps an array to a function. We must rename this dangerous function to call_a_function_on_every_element_of_an_array - or, even better, remove it from the language core ENTIRELY. If it was a private function used inside the runtime, maybe that would be fine, but it's a public part of the API.
>I have never, ever seen nl2br referred to as making anything secure or safe.
There is also no mention in the manual that it is unsafe! One of the big problems with PHP is how easy it is to write dangerous code and how the standard manuals and tutorials often give little explanation to this.
It should be better documented to not directly print user input in HTML context, and there should be a very obvious best-practices[1] guide for newbies explaining what to do (and what not to do). But nl2br could only be dangerous is you misunderstand the function's name, description, sample code, and everything else on the documentation.
> By passing text to something that replaces new lines with br the implication is that it is now safe to drop into HTML
> I don't see how that's implied at all. After all, the function is named nl2br, not html2text.
Absolutely every example from the documentation http://php.net/manual/en/function.nl2br.php uses it exactly in this manner: taking the output and immediately outputting it to the resultant HTML document. I've already described why this is unsafe (take any of these examples, replace the string with something like "Everyone knows 4 < 5", and it breaks the document due to the inclusion of "special" characters).
Now you feel that the correct use of this function is so obvious that it merits mocking my belief that it may be misunderstood by users (despite the comments on that very documentation page describing how they use it as a simple text to html converter). So given that it is so obvious to you, I repeat my original request: just give me an example where nl2br isn't ultimately used to transform plaintext before outputting it to HTML.
Have you actually read the PHP documentation page for nl2br? People are absolutely using it that way and not making any remark about safety or security. As an anecdote, when I started using PHP, I began to use nl2br to change the newlines in my HTML to <br> tags and output them. You can mark that up to me being a bad developer I guess but I literally got the idea from the PHP manual.
Also, your criticism of map() is kind of childish. It doesn't imply to a new learner that they will draw a map, nor does the documentation even hint at anything like that. In the Python documentation, they are given a clear use case and, if they are familiar with programming (or linguistics), understand that usage of the word map as a verb. Don't be obtuse about PHP's bad documentation.
It's named quite well and explains exactly what it does. If you think this converts text to html you haven't read the manual. RTFM before programming or get out of the fucking field.
Correct. I've gone with his latter solution for now and added a warning about import order. I'm not very happy with this solution through and will be spending some time with ctypes in the next few days to come up with something better.
The first answer mentions a couple of time that any token given to the user (for remember-me login or password reset) should be hashed in the database.
Would it be possible to replace the whole storing by signing the token with some private key, so that the validity of the token can be checked without having to compare it to some stored value ?
Yes, you could use an HMAC for this, however you need to keep the private key, well... private, which in practice is not easy. If the server is compromised, an attacker could steal the secret key and use it to generate signed cookies for any user. This method is also subject to reply attacks for the duration of the token's validity, though that is less relevant with SSL.
Whereas if only token hashes are stored in the database, then the entire database could be stolen and nobody can use it to generate valid cookies.
EDIT: Also, if an account goes rogue you have no way to invalidate its cookies, so you'll have to do a lookup for each request to see if the account is blocked.
Not as sexy as some of the things you can find on this page, but :
https://github.com/madjar/pyramid_persona/ : a lib to use the persona auth system from mozilla with the pyramid web framework (that is specific !)
One of the biggest advantages is the fact this is not multi-threading, so context switches can only happen at precise points (yield from). This makes it easier to reason about the code.