I recommend calling the column user_id in both tables. The column in pwd should also have a foreign key constraint like REFERENCES user ON DELETE CASCADE. Or it could be in the same table: Using a separate table is usually only worth it if the rows are big or the relation is not one on one.
I recommend calling the column `user_id` in both tables. The column in `pwd` should also have a foreign key constraint like `REFERENCES user ON DELETE CASCADE`. Or it could be in the same table: Using a separate table is usually only worth it if the rows are big or the relation is not one on one.
You can probably use a Result<Value, Status> for most endpoints and avoid a custom enum. I also recommend using json::Value qualified like that because Value by itself is not very descriptive.
You can probably use a `Result<Value, Status>` for most endpoints and avoid a custom enum. I also recommend using `json::Value` qualified like that because `Value` by itself is not very descriptive.
True, but in the future we might want to return a status on a non error condition, or return a Redirect, I understand it is a bit overkill now, but in a previous iteration I was also returning Redirects and then this becomes a nice solution imho.
True, but in the future we might want to return a status on a non error condition, or return a Redirect, I understand it is a bit overkill now, but in a previous iteration I was also returning Redirects and then this becomes a nice solution imho.
I think you can use a Request Guard (see https://api.rocket.rs/v0.5-rc/rocket/request/trait.FromRequest.html) to authenticate the user and role: For example, endpoints that require admin privileges could accept a non-optional Admin struct containing a user id and the request guard that generates it would only return Success if the user is logged and has the admin role.
I think you can use a Request Guard (see https://api.rocket.rs/v0.5-rc/rocket/request/trait.FromRequest.html) to authenticate the user and role: For example, endpoints that require admin privileges could accept a non-optional `Admin` struct containing a user id and the request guard that generates it would only return `Success` if the user is logged and has the admin role.
Reading more carefully I see you're already doing this, just that you're accepting an Option<User> and then checking it's not None while you could accept a User and be sure.
Reading more carefully I see you're already doing this, just that you're accepting an `Option<User>` and then checking it's not `None` while you could accept a `User` and be sure.
We'll it is, it's an application level error, so it's a valid request and you will get a valid http response with an "Failure" result. So that's why it returns an actual Json value
We'll it is, it's an application level error, so it's a valid request and you will get a valid http response with an "Failure" result. So that's why it returns an actual Json value
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Lucus
yorick
8a41ddec86toa1b0611abfa1b0611abfto33ed736f0c33ed736f0ctob8c246f521b8c246f521toaf0dcee1595bf581356atoa3f70b8ad7a3f70b8ad7todf8b553345@@ -0,0 +301,4 @@pub email: String,#[validate(length(min = 10), must_match = "password_repeat")]pub password: String,pub password_repeat: String,Ik zou password_repeat checks in de frontend doen, als je die dan toch hebt.
Het plan is om beide te doen, want als je dan de frontend checks omzeilt krijg je alsnog narigheid. want je kan ook gewoon tegen de api aan praten.
@@ -0,0 +1,42 @@use rocket::fs::NamedFile;use rocket::http::Method;use rocket_cors::{AllowedHeaders, AllowedOrigins, Cors, CorsOptions};| ^^^^^^^^^^^ use of undeclared crate or module
rocket_cors@@ -0,0 +1,43 @@ex<!DOCTYPE html>ex
@@ -0,0 +6,4 @@);CREATE TABLE pwd (id INTEGER NOT NULL PRIMARY KEY,I recommend calling the column
user_idin both tables. The column inpwdshould also have a foreign key constraint likeREFERENCES user ON DELETE CASCADE. Or it could be in the same table: Using a separate table is usually only worth it if the rows are big or the relation is not one on one.@@ -0,0 +129,4 @@.values((pwd::id.eq(ids[0]), pwd::password.eq(&password_hash))).execute(c)})}).await {Wel mooi om de grote expression waar je hier op matcht even een naam te geven zodat de match leesbaar blijft.
@@ -0,0 +16,4 @@<input type="submit"></form></body></html>11
865ff9ac0eto87c2e0238087c2e02380to216571a45f216571a45fto5f73d556c6@@ -0,0 +17,4 @@use validator::ValidateArgs;#[derive(Debug, Responder)]pub enum ApiResponseVariant {You can probably use a
Result<Value, Status>for most endpoints and avoid a custom enum. I also recommend usingjson::Valuequalified like that becauseValueby itself is not very descriptive.True, but in the future we might want to return a status on a non error condition, or return a Redirect, I understand it is a bit overkill now, but in a previous iteration I was also returning Redirects and then this becomes a nice solution imho.
@@ -0,0 +113,4 @@}#[get("/gamenights")]pub async fn gamenights(conn: DbConn, user: Option<schema::User>) -> ApiResponseVariant {I think you can use a Request Guard (see https://api.rocket.rs/v0.5-rc/rocket/request/trait.FromRequest.html) to authenticate the user and role: For example, endpoints that require admin privileges could accept a non-optional
Adminstruct containing a user id and the request guard that generates it would only returnSuccessif the user is logged and has the admin role.See also the examples under the header "Request-Local State" in the above link.
Reading more carefully I see you're already doing this, just that you're accepting an
Option<User>and then checking it's notNonewhile you could accept aUserand be sure.@@ -0,0 +149,4 @@.select(user::id).get_results(c){Ok(id) => id[0],generates a panic if the user does not exist
@@ -0,0 +149,4 @@{Ok(()) => (),Err(error) => {return ApiResponseVariant::Value(json!(ApiResponse::error(error.to_string())))Value is not an error response
We'll it is, it's an application level error, so it's a valid request and you will get a valid http response with an "Failure" result. So that's why it returns an actual Json value
@@ -0,0 +155,4 @@match schema::insert_user(conn, register).await {Ok(_) => ApiResponseVariant::Value(json!(ApiResponse::SUCCES)),Err(err) => ApiResponseVariant::Value(json!(ApiResponse::error(err.to_string()))),Value is not an error response
@@ -0,0 +121,4 @@.eq(&new_user.username).and(user::email.eq(&new_user.email)),).select(user::id)called
user_idnow