[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.