ayanova/devdocs/todo.txt

@@ -75,6 +75,44 @@ CURRENT ITEM:
 	- also User model, login and password are not set to required
 	- also auth route with dubious expectation about salt being only necessary differentiator and collection returned from login which should be one only now after this change
 
+
+
+todo: integration tests bombing due to side effect of dltoken creation changing concurrency token for User account 
+	in high speed multiple login scenario, between fetch at start of auth and save of dl token concurrency token has changed by another login
+	which if same account login again breaks
+	FIX: fix below and implment new dl token plan will fix this
+
+todo: JWT tokens, revoking expiring etc, look at this: https://github.com/ptboyer/restful-api-design-tips#authentication
+todo: PLANNING session tracking to prevent logging in from multiple devices with same account
+	- right now if I login as same user on another browser the download token becomes invalid on the first computer
+	- so wiki images don't load etc
+	- Perhaps we track the download token or something during certain requests to server so it can return a 403 and redirect to login if they are on another session
+	- or maybe the download route should return the not authenticated response to force login again
+	- maybe part of JWT session key of some kind that must be current to work to prevent multiple logins
+	- JWT TOKEN for image download??
+	- JWT TOKEN too large?  sb as tiny as possible, currently too much info in it?
+	ACTION:
+		- First determine if this is a bad thing or should be supported to some degree.
+		- like, maybe user is in more than one tab at the same time?
+		- or, maybe user is signed in at office and on road and needs both up??
+		- Is there *any* reason to support this considering users can just make as many accounts as they need to ensure no overlap.
+		- what could go wrong other than dl tokens?
+		- See if jwt gets sent back to server with the dl token, if not, consider adding it somehow so can ensure it's still valid at server
+		- if not valid then sends a 401 not authorized
+
+todo: User dl token and other data in JWT not required should be fetched seperately
+		Currently in token WAY too much stuff:
+		{ "iat", iat.ToUnixTimeSeconds().ToString() },
+		{ "exp", exp.ToUnixTimeSeconds().ToString() },//in payload exp must be in unix epoch time per standard
+		{ "iss", "ayanova.com" },
+		{ "id", u.Id.ToString() },
+		{ "name", u.Name},
+		{ "usertype", u.UserType},
+		{ "ayanova/roles", ((int)u.Roles).ToString()},
+		{ "dlt", DownloadToken }
+
+
+
 Fix existing integration tests
 Add tests as I go while adding all the structure of the workorder and all ops 
 	TBD: Does a labor and other grandchild objects record really have an attachment, wiki, and custom fields?
@@ -384,25 +422,6 @@ todo: change trial detection route that client first hits
 	- maybe the route that gets Notifications
 		- because there could be a notificatoin type that doesn't need logged in users for general server down announcements etc
 
-todo: JWT tokens, revoking expiring etc, look at this: https://github.com/ptboyer/restful-api-design-tips#authentication
-todo: PLANNING session tracking to prevent logging in from multiple devices with same account
-	- right now if I login as same user on another browser the download token becomes invalid on the first computer
-	- so wiki images don't load etc
-	- Perhaps we track the download token or something during certain requests to server so it can return a 403 and redirect to login if they are on another session
-	- or maybe the download route should return the not authenticated response to force login again
-	- maybe part of JWT session key of some kind that must be current to work to prevent multiple logins
-	- JWT TOKEN for image download??
-	- JWT TOKEN too large?  sb as tiny as possible, currently too much info in it?
-	ACTION:
-		- First determine if this is a bad thing or should be supported to some degree.
-		- like, maybe user is in more than one tab at the same time?
-		- or, maybe user is signed in at office and on road and needs both up??
-		- Is there *any* reason to support this considering users can just make as many accounts as they need to ensure no overlap.
-		- what could go wrong other than dl tokens?
-		- See if jwt gets sent back to server with the dl token, if not, consider adding it somehow so can ensure it's still valid at server
-		- if not valid then sends a 401 not authorized
-
-
 
 
 todo: Server serialized fields, it should *not* be getting the value from the table but rather have it's own table with last number assigned instead