auth: add function to create ad-hoc authenticated contexts
auth: update user type constants
Those need to be kept in sync with the database/GraphQL values. The ones
not in sync are not currently used, though.
server: let AUTH_INTERNAL access @anoninternal
Both methods enforce the internal aspect, but @anoninternal really just
means the resolver does not require an "authenticated user" context,
which means it's still perfectly safe if there is one.
With this in place, any resolver that may have to be called from an
anonymous context can be switched from @internal to @anoninternal
without breaking existing users. Of course it can only be switched if it
really does not require a user context.
Don't uppercase error messages
auth/middleware: return semantic errors on auth failure
This time with a much simpler approach than the last one that caused
some authentication issues for chat.sr.ht.
auth: ensure semantic errors are bubbled up to user properly
auth: add error code on unauthorized request response
auth: handle edge case when fetching users from meta
Don't prevent suspended users from authenticating
With cookies or internal auth. The frontends already prevent users from
accessing services while suspended, and there are some complications if
we don't let the frontends access the backends at all if the
authenticated user is suspended.
auth: remove legacy OAuth support
auth: fix remote IP determination for audit log
This is probably isolated to dev or other small environments, but I had
two issues with the remote IP determination, breaking the audit log
display in my dev env after fairly standard usage.
The gist is that the audit log is designed to contain clean IP addresses
only. However, the algorithm starts out with `r.RemoteAddr`, which may
contain a port (usually 127.0.0.1:xxxxx). The port removal is already
performed at the beginning of the function, so simply re-use the result
of this.
Furthermore, the initial value (containing the port leading to breakage)
landed in the audit log because I was using a private IP (it's my dev
evn). We correctly trust private IPs, but that means if no public IP
ever shows up in the X-Forwarded-For header, the last private IP was the
one that actually made the request.
I am not entirely sure why this showed up now. I already had a bunch of
oder audit log entries that had the correct private-but-not-localhost
addresses. But in the current state, e.g. simply updating my profile
would cause the bad IP:port notation to be written to the audit log.
webhooks: implement internal webhook users
AUTH_INTERNAL requests previously could not register webhooks. This
commit adds the necessary changes to allow for this.
auth: use config.IsInternalIP
auth: reduce scope of user_type
auth: grant scoped access to anon internal auth
Internal auth is granted access to everything, whereas anonymous
internal auth is pretty restricted. This is mostly to avoid accidentally
hitting resolvers that require a logged-in user, however. Given that all
anon internal use cases are hard-coded and tested, this seems like a
pretty low risk. Allowing this will have the huge benefit of making much
more information available to anon internal queries, which will unlock
removing a bunch of awkward work-arounds we put in place.
Note, however, that this is also a work-around. It saves us from adding
yet more work-arounds to the GQL schema, and in the meantime a redesign
of the schema (especially the directives) is being worked on.
auth/middleware: fix user_type on new users
auth/middleware: convert user types to uppercase
server: use routing groups
Instead of hardcoding some exceptions in the auth middleware, use a
different routing group for routes that do not require auth. Makes the
auth middleware more generic and also removes a lot of unneccessary
middleware processing from routes that don't need it.
For now, the added group is not accessible from outside the module, but
if the need arises, this might be an option.