This commit is contained in:
@@ -3,84 +3,11 @@
|
|||||||
{"login": "OpsAdminLimited","password": "OpsAdminLimited"}
|
{"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_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
|
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
|
it sounds just like the option in ayaNova to erase all data but those are two different things
|
||||||
"permanently" is redundant as well.
|
"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?
|
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
|
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
|
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
|
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
|
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: 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
|
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?
|
also maybe direct immediate email bypassing generator?
|
||||||
Add backup fail to this will stub out for now
|
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: 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
|
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
|
todo: https, hosting production etc
|
||||||
https://docs.microsoft.com/en-us/aspnet/core/security/docker-https?view=aspnetcore-3.1
|
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
|
TODO: BETA TRIAL AUTH ISSUE
|
||||||
maybe they get their own trial instance or something
|
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
|
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
|
todo: tag refcount
|
||||||
Move this into a procedure, it's apparently quite slow now that I can see the metrics
|
Move this into a procedure, it's apparently quite slow now that I can see the metrics
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user