This commit is contained in:
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user