147 lines
9.2 KiB
Plaintext
147 lines
9.2 KiB
Plaintext
{"login": "manager","password": "l3tm3in"}
|
|
|
|
|
|
|
|
|
|
todo: MAYBE a datetime kind of parameter is interpreted as LOCAL by the server on a route
|
|
so what the fuck
|
|
sent from client http://localhost:7575/api/v8.0/server-metric?maxRecords=400&tsStart=2020-05-27T13:07:39.068Z&tsEnd=2020-05-27T19:07:40.068Z
|
|
At server route: tsStart: {2020-05-27 6:07:39 AM} tsEnd: {2020-05-27 12:07:40 PM} Kind=local for both
|
|
so actually that's all good so far, how about the query itself?
|
|
|
|
2020-05-27 12:13:38.6439|DEBUG|Microsoft.EntityFrameworkCore.Database.Command|Executing DbCommand [Parameters=[@__tsStart_0='2020-05-27T06:13:32' (DbType = DateTime), @__tsEnd_1='2020-05-27T12:13:33' (DbType = DateTime)], CommandType='Text', CommandTimeout='30']
|
|
SELECT a.t, a.allocated, a.cpu, a.gen0, a.gen1, a.gen2, a.privatebytes, a.workingset
|
|
FROM ametricmm AS a
|
|
WHERE (a.t >= @__tsStart_0) AND (a.t <= @__tsEnd_1)
|
|
ORDER BY a.t DESC
|
|
2020-05-27 12:13:38.8848|INFO|Microsoft.EntityFrameworkCore.Database.Command|Executed DbCommand (241ms) [Parameters=[@__tsStart_0='2020-05-27T06:13:32' (DbType = DateTime), @__tsEnd_1='2020-05-27T12:13:33' (DbType = DateTime)], CommandType='Text', CommandTimeout='30']
|
|
SELECT a.t, a.allocated, a.cpu, a.gen0, a.gen1, a.gen2, a.privatebytes, a.workingset
|
|
FROM ametricmm AS a
|
|
WHERE (a.t >= @__tsStart_0) AND (a.t <= @__tsEnd_1)
|
|
ORDER BY a.t DESC
|
|
|
|
Well, shit. The query is sending local time to the db server, so any query that sends to teh server needs teh values converted to utc first
|
|
This is malarky pure and simple!
|
|
:)
|
|
|
|
If change parameters to DateTimeOffset from DateTime and rerun exact steps as above:
|
|
2020-05-27 12:21:49.8196|INFO|Microsoft.EntityFrameworkCore.Database.Command|Executed DbCommand (21ms) [Parameters=[@__tsStart_0='2020-05-27T13:21:48.4840000+00:00', @__tsEnd_1='2020-05-27T19:21:49.4840000+00:00'], CommandType='Text', CommandTimeout='30']
|
|
SELECT a.t, a.allocated, a.cpu, a.gen0, a.gen1, a.gen2, a.privatebytes, a.workingset
|
|
FROM ametricmm AS a
|
|
WHERE (CAST(a.t AS timestamp with time zone) >= @__tsStart_0) AND (CAST(a.t AS timestamp with time zone) <= @__tsEnd_1)
|
|
ORDER BY a.t
|
|
|
|
* Now it properly is sending the value to the db in UTC as it stays IN utc from input to query
|
|
One thing though is it's casting the query to a timestamp with timezone which is weird but maybe because the column is defined as timestamp witout timezone
|
|
|
|
going to try
|
|
changing the model to datetimeoffset
|
|
change database schema for mmetric to with timezone
|
|
no, actually for me it's better without because it will never try to interpret or change it, it will just return and accept it as is and
|
|
that's what I want if I'm only dealing in UTC
|
|
rerun again and see if it's casting still
|
|
|
|
OK, after some research I am doing the correct thing, it should be:
|
|
Schema: "timestamp" Model: DateTime
|
|
The only issue may be in the interpretation of the date time, it's sent to postgres as is so if the server converts it as local from the parameter in the route then that's waht's sent
|
|
which is what I'm seeing in metric route so it's a translation of the datetime incoming to route parameter issue only and only when it hits the db for storage or query
|
|
|
|
2020-05-27 12:51:51.1443|INFO|Microsoft.EntityFrameworkCore.Database.Command|Executed DbCommand (4ms) [Parameters=[@__ToUniversalTime_0='2020-05-27T13:51:49' (DbType = DateTime),
|
|
@__ToUniversalTime_1='2020-05-27T19:51:50' (DbType = DateTime)], CommandType='Text', CommandTimeout='30']
|
|
SELECT a.t, a.allocated, a.cpu, a.gen0, a.gen1, a.gen2, a.privatebytes, a.workingset
|
|
FROM ametricmm AS a
|
|
WHERE (a.t >= @__ToUniversalTime_0) AND (a.t <= @__ToUniversalTime_1)
|
|
ORDER BY a.t
|
|
Ok, so the WHERE bit absolutely needs the to universal time to fixup the parameter that came in wrong
|
|
|
|
Storage?? I best check that shit use eventlog...
|
|
Yes event log is properly inserting with utc time:
|
|
2020-05-27 12:51:57.3213|INFO|Microsoft.EntityFrameworkCore.Database.Command|Executed DbCommand (10ms) [Parameters=[@p0='2', @p1='0', @p2='12', @p3='2020-05-27T19:51:56' (DbType = DateTime), @p4=NULL, @p5='1'], CommandType='Text', CommandTimeout='30']
|
|
INSERT INTO aevent (ayevent, ayid, ayatype, created, textra, userid)
|
|
VALUES (@p0, @p1, @p2, @p3, @p4, @p5)
|
|
RETURNING id, xmin;
|
|
|
|
Ok, that's internally, but waht about a record sent in from the client?
|
|
### Try Widget
|
|
Posted as: {"id":0,"concurrency":0,"name":"TEST DATE FUCKERY","serial":0,"dollarAmount":123,"active":null,"userType":2,"startDate":"2020-05-27T19:20:00.000Z","endDate":"2020-05-27T20:00:00.000Z","notes":"3333","count":"333","wiki":null,"customFields":"{\"c2\":\"3333\"}","tags":[],"userId":null}
|
|
12:20 to 1:00 pm was selected in client
|
|
Fetched back as:
|
|
{"data":{"id":2751,"concurrency":11535962,"name":"TEST DATE FUCKERY","serial":2751,"dollarAmount":123.0000,"active":null,"userType":2,"startDate":"2020-05-27T19:20:00Z","endDate":"2020-05-27T20:00:00Z","notes":"3333","count":333,"wiki":null,"customFields":"{\"c2\":\"3333\"}","tags":[],"userId":null}}
|
|
so identically which is good
|
|
Stored in DB AS:
|
|
Start date: 2020-05-27 19:20:00 End date: 2020-05-27 20:00:00
|
|
Ok, so a widget is utc at all aspects and is good!
|
|
|
|
## HOLUP
|
|
Ok, though I had it all worked out but then I'm seeing incoming back to client the dates from metrics of this:
|
|
2020-05-28T02:57:58.968205Z for 2020-05-27 12:57:58 Which is absolutely wrong, probably 7 hours ahead, not behind
|
|
I must be reconverting somewhere
|
|
Widget tests ok end to end, it's just in that metric controller fuckery
|
|
|
|
|
|
|
|
TODO: Why is this adding UTC bit to this query check the source code maybe something is up
|
|
Schema settings mean that pg will ignore any tz specification so in theory it's ignored, but...
|
|
|
|
SELECT a.gid, a.xmin, a.created, a.exclusive, a.jobinfo, a.jobstatus, a.jobtype, a.name, a.objectid, a.objecttype, a.startafter, a.subtype
|
|
FROM aopsjob AS a
|
|
WHERE ((a.startafter < NOW() AT TIME ZONE 'UTC') AND (a.exclusive = @__exclusiveOnly_0)) AND (a.jobstatus = 1)
|
|
ORDER BY a.created
|
|
2020-05-27 12:51:57.2585|INFO|Microsoft.EntityFrameworkCore.Database.Command|Executed DbCommand (10ms) [Parameters=[@__exclusiveOnly_0='False'], CommandType='Text', CommandTimeout='30']
|
|
SELECT a.gid, a.xmin, a.created, a.exclusive, a.jobinfo, a.jobstatus, a.jobtype, a.name, a.objectid, a.objecttype, a.startafter, a.subtype
|
|
FROM aopsjob AS a
|
|
WHERE ((a.startafter < NOW() AT TIME ZONE 'UTC') AND (a.exclusive = @__exclusiveOnly_0)) AND (a.jobstatus = 1)
|
|
ORDER BY a.created
|
|
|
|
|
|
todo: Are serial numbers working properly, I'm seeing gaps in widget but it could be because of unit testing
|
|
|
|
todo: leave running check it does overnight backup properly
|
|
|
|
todo: add backup turn off setting
|
|
environment variable
|
|
todo: add backup master time out setting
|
|
environment variable
|
|
|
|
TODO: BIG UPDATE ALL GUTS
|
|
|
|
|
|
todo: notification?
|
|
|
|
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.
|
|
|
|
DEPLOY AND TEST
|
|
|
|
todo: Test backup on Linux
|
|
- going to need to run in vm I think maybe |