From aeb3392b647c977df0c0906f01ebebc410d2e6c6 Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Sat, 20 Jun 2020 22:49:39 +0000 Subject: [PATCH] --- devdocs/todo.txt | 99 ++++++++++-------------------------------------- 1 file changed, 19 insertions(+), 80 deletions(-) diff --git a/devdocs/todo.txt b/devdocs/todo.txt index eb5dcd42..42a34f9a 100644 --- a/devdocs/todo.txt +++ b/devdocs/todo.txt @@ -3,84 +3,11 @@ {"login": "OpsAdminLimited","password": "OpsAdminLimited"} -LICENSE / ONBOARDING - - - - - -todo: FRESH PURCHASE ONBOARD - continue on with the steps required to purchase and use in production - -todo: chargeback license zapping - So need it to loop for while after a new purchase - maybe on a very long loop up to one year or something? - is it worth it to have this hassle, amount of fraud pretty low - maybe a check for updates route could handle this? - "Generally, consumers have to file a chargeback between 60 and 120 days from the time of the original purchase. After that happens, merchants have approximately 45 days to respond, if they wish to dispute it. " - - -todo: Rockfish - NOTE: this comes *from* RAVEN, not directly from client to Rockfish - trial request route - Post contact information and dbid - if previously exists then checks if email changing - or if not previously exists - Validates email independently - They need to click on a link to verify their email address - - -todo: rockfish - Email verification route NOTE: used by RAVEN, not directly from client to Rockfish - validates email already in customer trial account - triggers notification to *US* at our email address(s) that a new trial has validated email address ready for approval / rejection - -todo: rockfish UI list of trial requests open and their state - email verified or not - We click a button to accept or reject and can enter additional note for rejection which will be sent with reply - Rockfish sends a reply to user either saying they are accepted or rejected with reject reason note inserted - -todo: rockfish / RAVEN extra info with polling for license - in addition to license can put a notification into the return data - so we can contact a customer when we can't email them with a popup notification - -todo: RAVEN new job LicenseCheck - operates all the time on a 20 minute frequency as a built in job but only polls rockfish on schedule below - Automatically checks rockfish to see if there is a new license available and installs it if found - - Rockfish responses: - No new license, nothing to report: 204 NO CONTENT - No new license but something to report: 200 OK - data contains possibly one or more of: - NOTIFY: to be sent to the users (right now I can think of for the event of can't contact the customer but need to get a message to them) - CANCEL LICENSE POLLING: No more license polling with optional reason for user to see - Used when they have cancelled their subscription and would no longer like to purchase / renew - Raven makes a note in license table to stop polling - REVOKE LICENSE: immediately disable the license with notification message - used when there is fraud or revocation of payment after license was issued - Raven removes license entirely so it has no license at all - Store notification message in license table so will be showed at client in RED - New license returned for installation - Raven installs the license - - Polling frequency - If no polling in license table then no polling happens until some other operation clears this flag - If polling in license table and: - is unlicensed or expired trial, check on boot and every 30 minutes thereafter - is active trial or licensed, check on boot and then once every 24 hours thereafter - - - -################# todo: AYANOVA_SERVER_TEST_MODE Is this a thing anymore? I think I need to remove it as an environment variable and all the startup code to go with it todo: AYANOVA_PERMANENTLY_ERASE_DATABASE does more than that, also resets dbid, should this option name be changed to something more dire it sounds just like the option in ayaNova to erase all data but those are two different things "permanently" is redundant as well. - -todo: authentication login from IP address, it should really be an option or kept where it can be viewed but not overwhelm the log file - Maybe a switch to disable or mask it or fully enable so "AY_LOG_LOGIN" values "FULL" or "MASK" or "DEBUG_FULL" or "DEBUG_MASK" or "NONE" - Defaults to FULL - todo: permanently erase db startup thing, should it really exist? It will zap the dbid so a user might expect to just use their old license but it wont' fetch again we could issue a new key to replace with the new dbid and also issue a revoke key for the old dbid so that @@ -91,10 +18,9 @@ todo: could be a presentation issue but erasing the database and "permanently" e Maybe change the biz object erase to empty or remove all data or something along those lines If it requires too much explanation then it's probably mis-identified as to what it does + todo: docs, change all named references to the Manager / manager / admin / adminstrator account to "SuperUser" -TODO: do I really need to not log IP addresses on login? - check privacy stuff, this seems necessary for security TODO: restrict server so randos can't login since the client now has all the logins helpfully pre-loaded on it @@ -108,8 +34,6 @@ todo: OPS notification created for failed jobs also maybe direct immediate email bypassing generator? Add backup fail to this will stub out for now - - todo: Look for the comment //todo in the server source code and in each case turn into a todo here instead or in addition or remove if no longer an isue todo: (BREAK THIS OUT INTO LATER/NOW/CASES) there are several outstanding AUTHENTICATION related cases in rockfish for RAVEN @@ -145,12 +69,27 @@ todo: API docs, make separate page for datalists and remove from api-response-fo todo: https, hosting production etc https://docs.microsoft.com/en-us/aspnet/core/security/docker-https?view=aspnetcore-3.1 -TODO: When go to full beta trial for people to look at need it to handle simultaneous logins somehow - maybe they get their own trial instance or something - +TODO: BETA TRIAL AUTH ISSUE + When go to full beta trial for people to look at, can't have two people logging into the same exact instance + Potential solutions: + Unique instance spun up on demand + Ultimately this will be the actual ongoing solution to this issue + Kubernetes? + Makes a unique user on the fly for them to login with + with random unique password + i.e. EvalUser42 pw:234089234023498 + and resets each day on a loop + + MAYBE + +todo: authentication login from IP address, it should really be an option or kept where it can be viewed but not overwhelm the log file + Maybe a switch to disable or mask it or fully enable so "AY_LOG_LOGIN" values "FULL" or "MASK" or "DEBUG_FULL" or "DEBUG_MASK" or "NONE" + Defaults to FULL + LET"S CALL THIS A CADILLAC PROBLEM AND BUMP TO BOTTOM + todo: tag refcount Move this into a procedure, it's apparently quite slow now that I can see the metrics