By default Phoenix uses client side sessions. The session data is written into a cookie and signed (or encrypted) to prevent tampering.
1,525 karma · joined November 19, 2015
I think the only matter here related to the war could be that electricity sales companies might be reluctant to sell a contract to them, due to PR reasons. But I bet one of them will, and they will get their power back.
It runs on Elixir and I write blog posts by editing Markdown files over SFTP and calling a certain function on the blog instance to reload the files.
[0] https://blog.nytsoi.net [1] https://gitlab.com/Nicd/mebe-2
where X = Gated, Y = unknown senders, and Z = donate to charity.
[0] https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
"any" is the escape hatch and allows you to do anything with the variable. In essence it stops type checking entirely for that variable.
"unknown" takes the opposite approach and doesn't let you do anything with the variable value (other than pass it along to other "unknown" accepting variables/functions) until you have asserted its actual type with type guards.
I don't think so, as the Erlang documentation states that 1) the distribution protocol is in plaintext, 2) the cookie is not secure in the cryptographic sense, but in the sense that it will prevent accidents, and 3) the cookie handshake is not cryptographically secure.
It is not possible to generate a cookie that provides any true security as the distribution protocol is plaintext and the cookie handshake is not secure. Claiming to get any security benefit from a "stronger" cookie would only give a false idea to the user.
Erlang does not start distribution by default. This is done by the user of Erlang, or the application that runs on Erlang. It is up to them to make sure that their environment is secure and that they understand how Erlang distribution works. Namely, to not open ports in the firewall willy nilly and only allow communication to them from an isolated network or over TLS. Frankly I don't know what you would expect Erlang to do here, maybe to add even bigger warnings to the documentation?
The problem here is application developers not understanding how to configure their application to be secure by default. They are the ones opening the distribution wide to the Internet and not advising their users on how to do it safely, not Erlang.
This is exactly how I would word the issue. If an attacker can talk to the Erlang distribution port with nothing but the cookie preventing them, then the system is already lost. That should never happen, the distribution ports should only be open on an isolated internal network for the other cluster members.
If RabbitMQ opens these ports by default and does not document the issue clearly, then that is the failing. I don't think fixing whatever random number generator is generating the cookie will make the system secure enough to be considered fixed. At worst it may give a false sense of security when in reality the fix has been made in the wrong location.
> "Security" here does not mean cryptographically secure, but rather security against accidental misuse, such as preventing a node from connecting to a cluster with which it is not intended to communicate.
The purpose of the cookie is to guard against _accidental misuse_, such as a user connecting to the wrong node (prod vs testing?). The cookie is not meant to secure a system against unauthorised use. Any system relying on the cookie for security should already be considered broken. Thus I can see why there has not been such hurry to "fix" the issue.
[0] https://en.wikipedia.org/wiki/Onkalo_spent_nuclear_fuel_repo...
In my own service I plan to offer users the ability to define a "stylised" nickname and an alternative text for screen readers, should they be interested in it (like an alt text for images). If Twitter had such a feature, I'd use it because I really like the effects, even if they're cheesy. :)
But the first pain point I very much agree with. Implicitly sending queries to the backend is one of those things that is an attempt to be very helpful to programmers, but that ends up as an obstacle that you always need to be wary of and avoid. Over time I have grown to appreciate explicitness in queries more and more, though I probably wouldn't go so far to remove lazy queries completely since they can be handy in query building, just remove the implicit loading feature if possible.
Django's query builder is also quite far removed from SQL. Especially once you get into more complex queries, I sometimes just went raw SQL as I knew I wouldn't be able to remember how to translate the Django expression into SQL in a month's time. Simple queries are easy to write and look very sleek, but complex ones can turn into a mess that is much more understandable in SQL form. The sleekness of the queries may also betray how complex they are to execute as it's not "in your face".
I still like Django's ORM quite a bit for many things, but after discovering Elixir's Ecto, I've enjoyed how explicit it is most of the time. I haven't needed implicit loading of relations once. It's also much closer to actual SQL. But there are things where Ecto also tries to be too helpful in my taste, like the humanised types in migrations (i.e. :utc_datetime instead of :timestamptz or :string instead of :"character varying"/:text) -- I strongly believe it would be easier in the long run for the programmer to specify the database types they want directly rather than through aliases which may result in surprising choices. Of course, that would cause issues in supporting multiple different databases, but that's not a goal I would go for in the first place, but I digress…
What I guess I'm saying is that sometimes projects build in helpful features to make the code nicer to look at, more approachable to beginners, or just shorter to write, but they often end up being a burden on those that go past the beginner stage. People invariably trip on them because who can remember everything mentioned in all the documentation? And then it's just a game of "who fails to avoid the trap every time" and that's a game that everyone loses eventually.
For me, getting a split keyboard was a matter of protecting my hands. I felt strain in my wrists and fingers when using a regular keyboard all day. With a split keyboard my wrists can stay straight and I was forced to learn the correct finger positions. I no longer use a mouse, but instead my keyboard's mouse layer keys, so I have no reason to move my hands away from the home position.
Of course most of the split keyboards, being made for enthusiasts, also contain a lot of other features like customisable firmwares and such.
I'm not sure about GMail's case, but I recall Mac OS X (back when it was called that) used to do something like this. Since showing a correct progress bar doesn't make it look so nice (it might be stuck at 90% for longer than it took to get there) and might be difficult to estimate, they instead wrote the last boot time into a file and on the next boot would render a smooth progress bar that would follow the timer. In my experience it made for a reasonable estimation of the boot time and I thought it was a clever solution.
I checked one and it contains 0.1g of sugar per 100g, but it's not added sugar, it's contained in the other ingredients. I don't know if it's possible to make it with absolutely 0g of sugar. But there is no separate ingredient "sugar" there.