Base member creation being added in this commit notes to follow
struct Member has had its field types changed to db_types::* types
Member::to_json was added to support simple json serialization into responses
struct InsertableMember added because `id` is generated by SQL for us
- this means we have to do two queries 1 to insert and 2 to fetch
- mysql_async does not provide an inlined way of fetching a recently added row
func general_new_user is only checking for a `name`parameter
- falls back to a basic default name for those that don't set a name on jooin
- handles its own sub errors so the main dispatcher doesn't care about after move
Generally more explicit behavior is provided
*NOTE: if this call succeeds then we have fully authenticated and subsequent calls should have acccess to "secret" in the serialized params structure, thus unwraps should be fine as they'll be proven via informal induction
Why: The idea is that writing a body parser is both really annoying and not really optimal
At this time I need some way of getting body params easily while endpionts are tested
at some point we'll come up with a smaller footprint way of parsing http parameters
Ideally one that also comes with the ability to combine parameters but,
for now using serde_json suffices.
InviteRow now has some utilities built into it to help with translating values from various types needed throughout the codebase
+from_tuple -> because mysql is used to grab tuples before structs
+as_json_str -> because we respond primarily with json payloads
list_channels is considered a main entry point from the dispather and thus handles errors itself
this lets us cut down on worrying about mysql errors
Mysql error responsibility is now the route dispatchers problem
Route dispatcher itself can easily dispatch to another handler
+ new() -> create a new ready to insert invite
+ from_tuple -> helps us translate db responses into a struct
+ as_json_str -> String which we can use as a json payload(jank but whatever it works with proper headers)
FUnctions:
get_invite_by_code: as the name implies grabs an invite assuming its in our db otherwise None
record_invite_usage: blindly modifies the row in the schema, assumes that if we get to this point we're ok to ignore erroneous possibilities
join_invite_code: main dispatcher for joining using the /invite/join route
create_invite: meant to the be the route handler for creating invites later on
Needed: test module since we've basically reworked the whole auth/invite system in one day
route dispatcher work begins with dispatching to invites::join_invite_code
Fixed the non mutable ref borrowing in funcs that required mutable references like most that get called by route_dispatcher
We can now decide what kind of authorization result triggers what kind of responses to the users
Further more error handling has to happen closer to application logic which is the main trade-off of our architecture
for now we're only going to use two methods to
auth::wall_entry is what allows to impose rate on a per user basic, not per route, although this feature can be configured later
