On Tuesday, October 25, 2016 at 10:01:48 AM UTC+1, Peter Damoc wrote: > > On Tue, Oct 25, 2016 at 11:27 AM, 'Rupert Smith' via Elm Discuss < > [email protected] <javascript:>> wrote: > >> If your 'persistence API' requires the application to behave correctly in >> order to not store invalid or maliciously altered data, you cannot >> guarantee that. >> > > This actually sounds more like a challenge to be faced rather that a > technical impossibility. > Maybe some kind of declarative access control embedded in a shared schema > could solve this. >
Declaring what the access rights are to the client UI is useful, yes - it is just that they still need to be enforced by the server because you cannot fully trust the client to take care of it. This is actually what I am doing (in some cases), because when a user logs in they get back a JWT token. This token contains some information about who the user is, and what permissions they have. The UI can use this to only render screens and functionality that the user is allowed to use. This is merely to be helpful and provide a nice user experience, the permissions are always checked whenever a restricted API endpoint is invoked. I don't always use the JWT tokens as bearer tokens in an HTTP Authorization header field, or as a secure cookie because they can grow quite large. However, I generally do provide an endpoint in my API where the JWT token can be requested in order to inspect the users declared access rights. > I do think that these server side responsibilities are not really within >> the domain of Elm. > > > Look at what happened with Javascript. Once it got useful in the client > people wanted it on the server and then we got Node. > We are nowhere near the popularity of javascript and yet, I already see > frequent enough questions about using Elm on the server-side. > > There are two ways to address this: > 1. allocating resources to making Elm viable on the server > 2. making the server part as small and automatic as possible as to not > require much coding. > > To me, option 2 is much more attractive. > Ok, I think I now get a better idea of what you are after. As per John Kellys PostgREST code: https://github.com/john-kelly/elm-postgrest. Have a way of defining a data model in Elm, and use that description to automatically generate a suitable server to persist it. In this case defining the access rights in the Elm code would be ok, as the server that you generate would also securely check them at runtime. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
