8360efced5
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
48 lines
1.3 KiB
Rust
48 lines
1.3 KiB
Rust
use mysql_async::Conn;
|
|
use mysql_async::prelude::{params, Queryable};
|
|
use hyper::{Response, Body};
|
|
use std::collections::HashMap;
|
|
|
|
pub enum AuthReason {
|
|
Good,
|
|
LimitPassed,
|
|
NoKey,
|
|
InternalFailure,
|
|
}
|
|
|
|
fn check_key_row(row: Option<(String, i32, i32)>) -> AuthReason {
|
|
use self::AuthReason::*;
|
|
match row {
|
|
Some(data) => {
|
|
if data.2 > data.1 {
|
|
LimitPassed
|
|
}
|
|
else {
|
|
Good
|
|
}
|
|
},
|
|
None => NoKey
|
|
}
|
|
}
|
|
pub async fn wall_entry(conn: Conn, params: &HashMap<&str, &str>) -> AuthReason {
|
|
// Start by Checking if the api key is in our keystore
|
|
if let Some(key) = params.get("key") {
|
|
// (id, limit, current counter)
|
|
let db_request: Result<(Conn, Option<(String, i32, i32)>), mysql_async::error::Error> = conn
|
|
.first_exec(r"SELECT * FROM keys WHERE id = :id ", mysql_async::params!{ "id" => key})
|
|
.await;
|
|
|
|
// Error case should probably have some kind of error checking
|
|
match db_request {
|
|
Ok(db_tup) => check_key_row(db_tup.1),
|
|
Err(_) => AuthReason::InternalFailure
|
|
}
|
|
}
|
|
else {
|
|
AuthReason::NoKey
|
|
}
|
|
}
|
|
|
|
pub fn wall_failure(resp: &Response<Body>) {
|
|
unimplemented!()
|
|
} |