3 ms·

How does a raw UUID equate to encapsulated state? Adding a UUID doesn't inherently hide or restrict access to data.

seanmcdirmid 12y ago
Think about it like this: as long as you have an identity, someone can remember something about you...and therefore state! If you didn't have an identity, then that would be impossible, it is like a superpower where no one could "remember" who you are, and therefore nothing about you. A UUID is synonymous to state, and in fact, procuring and propagating these IDs would be the main step to implementing state in a pure language.
- weavejester 12y ago
  You said "encapsulated state". I was wondering why you thought it was encapsulated, which is usually a term for information hiding. I'm also not certain why you think this conflicts with the idea of talking "in terms of functions".
- williamcotton 12y ago
  A signed access token is how identity is provided in a stateless environment. Take Facebook OAuth for example. A user logs in, is provided with a signed access token by FB, and then uses that token to prove to an application that the owner of the secret key has granted them permission. The owner in this case was Facebook itself. This can be verified by the server by comparing the: var expectedSignature = crypto.createHmac('sha256', FACEBOOK_OAUTH_CLIENT_SECRET).update(encodedData[1]).digest('base64').replace(/\+/g,'-').replace(/\//g,'_').replace('=',''); with the signed request signature: var signature = signedRequest.split('.',2)[0]; and making sure that they're the same. This way the server never needs to maintain sessions, cookies, or a whole bunch of other crappy, centralized, coupled, insecure methods for building networked software. The server only needs the secret keys of whatever access tokens users might be providing. The access token contains the userId or any other relevant information. If the server needs more information about the user, it can provide the access token to another API that returns more information about the user, again, based solely on the access token, just by passing state INTO whatever system/function/service needs it. If this server is sitting in front of a database all that the server cares about is what the access permissions are of whatever incoming request it is dealing with. It still doesn't need to maintain state. The database is maintaining state, but the server is just verifying that the request can make the changes to the state of the database. All with the wonders of functions, modules, and APIs that try to operate without managing their own internal state, which again, is the main feature of functional programming languages.

Think about it like this: as long as you have an identity, someone can remember something about you...and therefore state! If you didn't have an identity, then that would be impossible, it is like a superpower where no one could "remember" who you are, and therefore nothing about you. A UUID is synonymous to state, and in fact, procuring and propagating these IDs would be the main step to implementing state in a pure language.

weavejester 12y ago
You said "encapsulated state". I was wondering why you thought it was encapsulated, which is usually a term for information hiding. I'm also not certain why you think this conflicts with the idea of talking "in terms of functions".
williamcotton 12y ago
A signed access token is how identity is provided in a stateless environment. Take Facebook OAuth for example. A user logs in, is provided with a signed access token by FB, and then uses that token to prove to an application that the owner of the secret key has granted them permission. The owner in this case was Facebook itself. This can be verified by the server by comparing the: var expectedSignature = crypto.createHmac('sha256', FACEBOOK_OAUTH_CLIENT_SECRET).update(encodedData[1]).digest('base64').replace(/\+/g,'-').replace(/\//g,'_').replace('=',''); with the signed request signature: var signature = signedRequest.split('.',2)[0]; and making sure that they're the same. This way the server never needs to maintain sessions, cookies, or a whole bunch of other crappy, centralized, coupled, insecure methods for building networked software. The server only needs the secret keys of whatever access tokens users might be providing. The access token contains the userId or any other relevant information. If the server needs more information about the user, it can provide the access token to another API that returns more information about the user, again, based solely on the access token, just by passing state INTO whatever system/function/service needs it. If this server is sitting in front of a database all that the server cares about is what the access permissions are of whatever incoming request it is dealing with. It still doesn't need to maintain state. The database is maintaining state, but the server is just verifying that the request can make the changes to the state of the database. All with the wonders of functions, modules, and APIs that try to operate without managing their own internal state, which again, is the main feature of functional programming languages.