[WorkLifeBalance]

How do you take this from here to the next step?

Let's say I want to develop a multi user todo and I've followed the examples and now have some Users who log in entering a password.

Someone points out that I shouldn't be storing passwords in plain text so I want to store them hashed.

Despite there being hints in the documentation that this is possible (migrations shows the password hashed), it's not clear how to carry out this kind of change.

A walkthrough of making a change would help convey the use case much better than just templates of "this incantation produces this output".

[klageveen]

Well, in this particular case passwords are always hashed. So the platform deals with that for you. Other changes to the data model need a migration, which is covered here: https://alan-platform.com/pages/tuts/migration.html

[CodesInChaos]

It looks like you're using SHA256(username||password) in this example. Even if it's only an example, why use a homebrew password hashing scheme based on an unsuitable hash function and bad ad-hoc salt handling, instead of a strong standard password hash with built in salt handling? And what code/specification is required to use a secure algorithm, like bcrypt with a random salt?

People often copy from such tutorials and will then end up with insecure password storage.

[byproxy]

As someone who's not a developer but still occasionally looks through these "build an app" tutorials, password/authentication portions always worry me. I wish I could know that best-practices were shown as far as storing/encrypting user data/passwords.

[WorkLifeBalance]

Where is the definition of the password being hashed? The tutorial defines it as text:

/* 'Users': collection { 'Password': text }*/

How does the platform know to hash that? Is it looking for magic property names?

[klageveen]

No, there is no magic :) When you set up the users at the top of the model file, you specify which property is the password.

[WorkLifeBalance]

Specifying something as password hashing as (sha256? salted sha256?) without telling it to seems like magic to me.

So to clarify, it's this password: declaration which tells the framework to hash the input?

    users
        dynamic :  . 'Users'
        password : . 'Password'

    interfaces

    root {

    }

    numerical-types

Is this defined anywhere within the project or is this framework magic? (Or "glue" if you don't like the term magic). password is not mentioned again anywhere in the documentation, I'd like to understand how the framework knows to hash the input.

[klageveen]

The line `password : . 'Password'` points at the password property, which tells the framework to hash it. What kind of hashing isn't something you should have to specify or worry about. It's a strong salted hash and we'd like to make it even better at some point, but that's firmly in the realm of the framework implementation.

[TheOtherHobbes]

This parses to "Just trust us to get this right."

I think you may have some issues persuading customers that's a wholly valid approach, especially when you're dealing with security and data integrity, GDPR, and so on.

[gcb0]

the goal is to "step in when excell starts to get in the way"

I doubt they will ever care about any of that. a "side loaded application" will likely be the answer to most of those comments.

[klageveen]

There is a lot the platform can do by itself, but I think you grasped it well enough. The side loaded apps are definitely the escape hatch to enable things it doesn't cover (yet).