| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
This reverts commit 831040c3d7dbc116a25848786bc5ab83fef6149b.
|
|
|
|
| |
This reverts commit de3f0b9e7003e4521f5ea866134e77ff859ab99b.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
- Remove sub-Makefiles; recursive make is annoying
- Just use one top-level Makefile that builds everything
- Embed templates and minified static resources into the binary
- Embed all compiled documentation into the binary and serve
- Embed all source into the binary and serve
|
|
|
|
| |
And adjust Makefiles, admin handbook, and lint.sh accordingly.
|
|
|
|
| |
Implements: https://todo.sr.ht/~runxiyu/cca/5
|
|
|
|
|
|
| |
This causes a drastic increase in performance.
References: https://todo.sr.ht/~runxiyu/cca/7
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Because of the poor performance of using NGINX as a reverse proxy, I've
added native TLS in commit 4a1a7af76408e956ebc343bf28960fdd00c00c58.
Serving static files was already supported, but it was expected that
people use a static web server to do so, so we didn't support
a configurable static path. Now since reverse proxy setups are
discouraged, it makes more sense to be better at serving static files.
|
| |
|
|
|
|
| |
This is useful for testing whether connection collisions work well.
|
|
|
|
|
| |
Fake authentication is useful when benchmarking the server with an
external program without going insane with the OpenID Connect forms.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
When propagate tries to propagate a message to a connection that
actually called propagate, it deadlocks because the it tries to send to
that connection's send channel in the same goroutine. This is an attempt
at a fix.
|
|
|
|
|
| |
We need to refer to courses by their ID, and a map makes significantly
more sense than a slice.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I am using a hybrid flow with "id_token" for OpenID Connect and "code" for an
Authorization Code. I would use "token" too but that doesn't seem to be
supported for standard web-apps and could result in strange session-hijacking
issues.
We still need PKCE sometime in the future; however it's not a priority: the
worst attack someone could pull off is to use a different user's Authorization
Code and steal a Department, which probably isn't too big of a deal as the
Authorization Code should be secret anyways.
|
|
These are imported from FBFP and slightly modified to be specific to YKPS
(while not being hard to port to other environments that use APIs that use
OAUTH 2.0). Some code is also simplified.
Database code still needs an audit, and things are not tested yet.
|