182 lines
8.7 KiB
Plaintext
182 lines
8.7 KiB
Plaintext
{"login": "superuser","password": "l3tm3in"}
|
|
|
|
{"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: 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
|
|
there can be no fraudulent use this way.
|
|
I guess it's a rare situation and if the option to delete is there people will surely fuck up and use it unintentionally?
|
|
or maybe not
|
|
todo: could be a presentation issue but erasing the database and "permanently" erasing the db do two different things completely
|
|
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
|
|
not sure how to do that and still support phone via cellular network or other people's wifi from logging in
|
|
Firewall settings I guess of some kind or maybe require a manual edit to the password, like add a 1 to the end of all of them or something?
|
|
|
|
|
|
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: (BREAK THIS OUT INTO LATER/NOW/CASES) there are several outstanding AUTHENTICATION related cases in rockfish for RAVEN
|
|
e.g. https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1924
|
|
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1835
|
|
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1998 <---this is an important case for consideration
|
|
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3367 <--time limited accounts for support or temporary access?
|
|
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/2059 <--- time restricted accounts so user can only login during business hours (still to be considered)
|
|
2fa stuff, some logging and lockout stuff
|
|
Go through the auth related cases and notes in client side and implement or close
|
|
todo: 2fa? (if not in first release, is there something needed to support it in future dbwise?)
|
|
todo: Auth Backdoor reset password feature
|
|
how to code it here, pretty easy to do:
|
|
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3250
|
|
todo: Look into 2fa
|
|
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3395
|
|
todo: look into how to use an SSL certificate with the RAVEN server directly when not behind nginx
|
|
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1
|
|
- this should be supported by default out of the box working with Let's encrypt ideally
|
|
- is it now considered ok to host .net core web api directly internet facing?
|
|
todo: onboarding and default manager account password
|
|
- Need to come up with a safety plan for this so people don't leave it at default
|
|
- Maybe the very first thing required of a user is to change the password before any tasks can be performed
|
|
- Server stays in safety lock until they set a password?
|
|
- Or maybe a random password is generated on seeding and somehow provided to user through console or something?
|
|
- Maybe an empty db if no other users can be set password only so no one has made a hidden backdoor user account before ops changes it?
|
|
- maybe tied to license if licensed so they bring some info they have from rockfish / their license purchase or something?
|
|
- don't want it to be onerous too much and have some very inexperienced users so...
|
|
- see what other programs do, like our forum software
|
|
|
|
todo: API docs, make separate page for datalists and remove from api-response-format.md doc but put a reference link to it there.
|
|
|
|
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
|
|
|
|
|
|
|
|
MAYBE
|
|
todo: tag refcount
|
|
Move this into a procedure, it's apparently quite slow now that I can see the metrics
|
|
|
|
todo: add backup master time out setting
|
|
environment variable
|
|
|
|
todo: add switch somewhere to "automatic backup" so can turn off in event of externally done backup
|
|
this will take backup processing out of the generator loop
|
|
but keep the backup ui so even if external, can download the backup files
|
|
|
|
c#, JSON, Markdown, xml, yaml, batch, html, linux shell, CSS, Javascript, SQL
|
|
|
|
LOC 2020-06-12 13:08:43
|
|
language files code comment blank total
|
|
C# 236 22,232 7,995 6,288 36,515
|
|
JSON 6 7,257 0 6 7,263
|
|
Markdown 98 1,818 0 920 2,738
|
|
XML 7 1,040 2 10 1,052
|
|
YAML 1 131 1 1 133
|
|
Batch 6 18 3 4 25
|
|
HTML 1 5 0 0 5
|
|
Shell Script 2 3 2 1 6
|
|
|
|
Vue 83 12,255 1,418 785 14,458
|
|
JavaScript 44 4,472 1,894 719 7,085
|
|
XML 5 243 1 6 250
|
|
JSON 3 174 0 2 176
|
|
Markdown 1 29 0 8 37
|
|
HTML 1 19 8 2 29
|
|
Batch 3 13 0 0 13
|
|
CSS 1 3 8 2 13
|
|
Ignore 1 1 0 0 1
|
|
|
|
C# 62 6,189 1,530 1,593 9,312
|
|
JSON 2 24 1 1 26
|
|
XML 1 18 0 2 20
|
|
|
|
C# 35 5,515 2,109 2,269 9,893
|
|
Batch 1 13 0 2 15
|
|
XML 1 13 0 4 17 |