I take away from this uncomfortable situation that I need to start thinking about how to channel all this 'productivity'. I hope to come up with a process that ensures forward progress from all this 'productivity' so that days after this eye opening experience I can guide everyones experience better.
I have experienced my first complete break down of working with people not like myself. It is disheartening to give up nights and weekends-- my own aspirations and extra time with the people I love most. I have chosen to make a sacrifice in the short term by investing in a project. I've given up some things dear to me for duty to an obligation. The motivation for accepting was thatI believe the investment will yield a comfortable schedule, much autonomy in my private and professional life, and a rewarding end result that makes the world a better place to live in because that matters to me.
Today I had to take time to be a better person than I was when I woke up. I am angry that people did not listen to my request to better themselves and know the subject material when directly asked to study. The pseudo code I received in the morning as part of a question made it clear that no effort was made to acquaint themselves with the concepts of this task.
I have experienced my first complete break down of working with people not like myself. It is disheartening to give up nights and weekends-- my own aspirations and extra time with the people I love most. I have chosen to make a sacrifice in the short term by investing in a project. I've given up some things dear to me for duty to an obligation. The motivation for accepting was thatI believe the investment will yield a comfortable schedule, much autonomy in my private and professional life, and a rewarding end result that makes the world a better place to live in because that matters to me.
Today I had to take time to be a better person than I was when I woke up. I am angry that people did not listen to my request to better themselves and know the subject material when directly asked to study. The pseudo code I received in the morning as part of a question made it clear that no effort was made to acquaint themselves with the concepts of this task.
Remember the movie The Matrix? I felt like the spoon kid in the Oracle's apartment. The whole time I'm thinking to myself, "Login, *creepy stare and mystical hand movements*, there is no login..."
The following is the resulting response e-mail regarding a 'login issue' that is actually an authentication & access issue:
This is a conceptual change in thinking. We keep saying login, but in reality this is merely a tool to persistently accept something given that we trust. (They get the trusted thing by supplying credentials but never actually 'log in'. They get the token and we forget about them essentially until they come back asking for something with the token.
The token is a tool to verify authentication on an ongoing basis. There is no 'state' preserved during the life of the token.
This is a conceptual change in thinking. We keep saying login, but in reality this is merely a tool to persistently accept something given that we trust. (They get the trusted thing by supplying credentials but never actually 'log in'. They get the token and we forget about them essentially until they come back asking for something with the token.
The token is a tool to verify authentication on an ongoing basis. There is no 'state' preserved during the life of the token.
It is okay to send as a header item as we are because SSL does encrypt it there-- we have maintained the user's privacy.
What makes us trust
them is that we have baked in a secret that cannot be distilled from the
whole. Since we made it and we know the secret, we can compare what we
received to a newly generated one (just like with comparing a password
hash to the hash created with a submitted password) -- we can trust a
token because we can verify that it has not been tampered with.
As
a bonus we can include very basic arbitrary data like a user id, their
name in text, and any organizations they belong to (eventually themeing
colors)-- this saves us some database lookup overhead.
However,
we must be careful with what data we decide to put in the token as this
increases the size of every request of a protected resource received
and many responses.
We are using PHP sessions with
AWS Redis flavored elasticache. At this time we are using it as a cache
to lighten the load on the database-- not as any part of authentication
or 'login'. We need to shift our thinking from the idea of 'logged in'
as an active user and more to the idea that the person is authenticated
and has access.
That changes the question from "is this person logged in" to "does this person have a valid thing we gave them"
Please adjust your code to match these concepts. If I were doing it, this is a method I might write.
validateRequest() {
if (isset(cookie('token')) && tokenIsValid()) {
if(!associatedCache()) {
get userObject by userId from token
store generatedUserObject
get orgObjects by associatedOrg[] from userObject
store generatedOrgObject[]
}
return '{"validToken":"true"'};
}
}
else {
//regardless of what is wrong with the token they need a new one
return '{"requestedResource":"' .
}
Since we are not using routing __FILE__ is meaningful data.return '{"requestedResource":"' .
__FILE__ . '","validToken":"false"}';}
*You might see some fibbing or incomplete things -- no logging, or cache invalidation, and a session token is more secure if we don't add any of our own arbitrary data in the second block of the JWT. That the info is available at all makes it 'less secure'. I've balanced the security against the convenience-- this is where the chips lay, I have some data in my JWT.
No comments:
Post a Comment