tandem/camper
tandem
/
camper
2
0
Fork 0
Code Issues 7 Pull Requests Packages Projects Releases Wiki Activity
camper/pkg/app/app.go

118 lines
2.6 KiB
Go
Raw Normal View History

Add the skeleton of the web application It does nothing more than to server a single page that does nothing interesting. This time i do not use a router. Instead, i am trying out a technique i have seen in an article[0] that i have tried in other, smaller, projects and seems to work surprisingly well: it just “cuts off” the URI path by path, passing the request from handler to handler until it finds its way to a handler that actually serves the request. That helps to loosen the coupling between the application and lower handlers, and makes dependencies explicit, because i need to pass the locale, company, etc. down instead of storing them in contexts. Let’s see if i do not regret it on a later date. I also made a lot more packages that in Numerus. In Numerus i actually only have the single pkg package, and it works, kind of, but i notice how i name my methods to avoid clashing instead of using packages for that. That is, instead of pkg.NewApp i now have app.New. Initially i thought that Locale should be inside app, but then there was a circular dependency between app and template. That is why i created a separate package, but now i am wondering if template should be inside app too, but then i would have app.MustRenderTemplate instead of template.MustRender. The CSS is the most bare-bones file i could write because i am focusing in markup right now; Oriol will fill in the file once the application is working. [0]: https://blog.merovius.de/posts/2017-06-18-how-not-to-use-an-http-router/
2023-07-22 22:11:00 +00:00
/*
* SPDX-FileCopyrightText: 2023 jordi fita mas <jfita@peritasoft.com>
* SPDX-License-Identifier: AGPL-3.0-only
*/
package app
import (
"net/http"
"path"
"strings"
Get user from database based on cookie and serve login if not logged in To get the user from the database i have to set the cookie first, that was already done in database.MustAcquire, but i thought they were too far apart, even thought they are so related. So, the cookie, and thus the role, is set when getting the user, that is actually the first thing to do once the connection is acquired. However, that way the database package has no knowledge of cookies, and the code that sets the cookie and retrieves the user are next to each other. I applied the same logic to the changes of locale.Match: it has not business knowing that the accept language string comes from a request; it only needs the actual string. Also, the TODO comment about getting the user’s locale made no sense, now, because app already knows that locale, so there is no need to pass the user to the locale package. Getting the locale is done after retrieving the user from the database, for the same reason the connection is Acquired as far up as possible: almost every request will need this value, together with the user and the database connection. I am a bit affraid that i will end up with functions that always expect these three values. Maybe i can put the locale inside user, as it is the user’s locale, after all, no matter if it came from the database or the user agent, but connection and user must be separate, i think. We’ll see.
2023-07-25 23:50:39 +00:00
"golang.org/x/text/language"
Include the locale inside the User struct The locale is completely dependent on the user, as much as its email or CSRF token, so it does not make much sense to have it in a separate variable: for different users we might have to use different locales. Also, this means one less variable to pass to handlers, that most of them will need the user at some point or another (i.e., to render its profile icon). The thing is that i can not import `app.User` from the template package because it would create an import cycle. I created the `auth` package just because of that. I thought that the login code would be better moved to the auth package as well, but of course then i would reintroduce the import cycle between auth and template.
2023-07-26 10:08:59 +00:00
"dev.tandem.ws/tandem/camper/pkg/auth"
Add the skeleton of the web application It does nothing more than to server a single page that does nothing interesting. This time i do not use a router. Instead, i am trying out a technique i have seen in an article[0] that i have tried in other, smaller, projects and seems to work surprisingly well: it just “cuts off” the URI path by path, passing the request from handler to handler until it finds its way to a handler that actually serves the request. That helps to loosen the coupling between the application and lower handlers, and makes dependencies explicit, because i need to pass the locale, company, etc. down instead of storing them in contexts. Let’s see if i do not regret it on a later date. I also made a lot more packages that in Numerus. In Numerus i actually only have the single pkg package, and it works, kind of, but i notice how i name my methods to avoid clashing instead of using packages for that. That is, instead of pkg.NewApp i now have app.New. Initially i thought that Locale should be inside app, but then there was a circular dependency between app and template. That is why i created a separate package, but now i am wondering if template should be inside app too, but then i would have app.MustRenderTemplate instead of template.MustRender. The CSS is the most bare-bones file i could write because i am focusing in markup right now; Oriol will fill in the file once the application is working. [0]: https://blog.merovius.de/posts/2017-06-18-how-not-to-use-an-http-router/
2023-07-22 22:11:00 +00:00
"dev.tandem.ws/tandem/camper/pkg/database"
Handle the login form I now actually handle the /login URL and check whether the email and password are valid, creating the session cookie if correct, but doing nothing else with that cookie, for now. The validation is done by hand for now, because i do not yet how i will actually do it without so much duplication.
2023-07-23 18:49:26 +00:00
httplib "dev.tandem.ws/tandem/camper/pkg/http"
Add the skeleton of the web application It does nothing more than to server a single page that does nothing interesting. This time i do not use a router. Instead, i am trying out a technique i have seen in an article[0] that i have tried in other, smaller, projects and seems to work surprisingly well: it just “cuts off” the URI path by path, passing the request from handler to handler until it finds its way to a handler that actually serves the request. That helps to loosen the coupling between the application and lower handlers, and makes dependencies explicit, because i need to pass the locale, company, etc. down instead of storing them in contexts. Let’s see if i do not regret it on a later date. I also made a lot more packages that in Numerus. In Numerus i actually only have the single pkg package, and it works, kind of, but i notice how i name my methods to avoid clashing instead of using packages for that. That is, instead of pkg.NewApp i now have app.New. Initially i thought that Locale should be inside app, but then there was a circular dependency between app and template. That is why i created a separate package, but now i am wondering if template should be inside app too, but then i would have app.MustRenderTemplate instead of template.MustRender. The CSS is the most bare-bones file i could write because i am focusing in markup right now; Oriol will fill in the file once the application is working. [0]: https://blog.merovius.de/posts/2017-06-18-how-not-to-use-an-http-router/
2023-07-22 22:11:00 +00:00
"dev.tandem.ws/tandem/camper/pkg/locale"
Get user from database based on cookie and serve login if not logged in To get the user from the database i have to set the cookie first, that was already done in database.MustAcquire, but i thought they were too far apart, even thought they are so related. So, the cookie, and thus the role, is set when getting the user, that is actually the first thing to do once the connection is acquired. However, that way the database package has no knowledge of cookies, and the code that sets the cookie and retrieves the user are next to each other. I applied the same logic to the changes of locale.Match: it has not business knowing that the accept language string comes from a request; it only needs the actual string. Also, the TODO comment about getting the user’s locale made no sense, now, because app already knows that locale, so there is no need to pass the user to the locale package. Getting the locale is done after retrieving the user from the database, for the same reason the connection is Acquired as far up as possible: almost every request will need this value, together with the user and the database connection. I am a bit affraid that i will end up with functions that always expect these three values. Maybe i can put the locale inside user, as it is the user’s locale, after all, no matter if it came from the database or the user agent, but connection and user must be separate, i think. We’ll see.
2023-07-25 23:50:39 +00:00
"dev.tandem.ws/tandem/camper/pkg/template"
Handle the login form I now actually handle the /login URL and check whether the email and password are valid, creating the session cookie if correct, but doing nothing else with that cookie, for now. The validation is done by hand for now, because i do not yet how i will actually do it without so much duplication.
2023-07-23 18:49:26 +00:00
)
Add the skeleton of the web application It does nothing more than to server a single page that does nothing interesting. This time i do not use a router. Instead, i am trying out a technique i have seen in an article[0] that i have tried in other, smaller, projects and seems to work surprisingly well: it just “cuts off” the URI path by path, passing the request from handler to handler until it finds its way to a handler that actually serves the request. That helps to loosen the coupling between the application and lower handlers, and makes dependencies explicit, because i need to pass the locale, company, etc. down instead of storing them in contexts. Let’s see if i do not regret it on a later date. I also made a lot more packages that in Numerus. In Numerus i actually only have the single pkg package, and it works, kind of, but i notice how i name my methods to avoid clashing instead of using packages for that. That is, instead of pkg.NewApp i now have app.New. Initially i thought that Locale should be inside app, but then there was a circular dependency between app and template. That is why i created a separate package, but now i am wondering if template should be inside app too, but then i would have app.MustRenderTemplate instead of template.MustRender. The CSS is the most bare-bones file i could write because i am focusing in markup right now; Oriol will fill in the file once the application is working. [0]: https://blog.merovius.de/posts/2017-06-18-how-not-to-use-an-http-router/
2023-07-22 22:11:00 +00:00
func shiftPath(p string) (head, tail string) {
p = path.Clean("/" + p)
if i := strings.IndexByte(p[1:], '/') + 1; i <= 0 {
return p[1:], "/"
} else {
return p[1:i], p[i:]
}
}
func methodNotAllowed(w http.ResponseWriter, _ *http.Request, allowed ...string) {
w.Header().Set("Allow", strings.Join(allowed, ", "))
http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
}
type App struct {
db *database.DB
fileHandler http.Handler
locales locale.Locales
defaultLocale *locale.Locale
languageMatcher language.Matcher
}
func New(db *database.DB) http.Handler {
locales := locale.MustGetAll(db)
app := &App{
db: db,
fileHandler: http.FileServer(http.Dir("web/static")),
locales: locales,
defaultLocale: locales[language.Catalan],
languageMatcher: language.NewMatcher(locales.Tags()),
}
var handler http.Handler = app
Handle the login form I now actually handle the /login URL and check whether the email and password are valid, creating the session cookie if correct, but doing nothing else with that cookie, for now. The validation is done by hand for now, because i do not yet how i will actually do it without so much duplication.
2023-07-23 18:49:26 +00:00
handler = httplib.RecoverPanic(handler)
handler = httplib.LogRequest(handler)
Add the skeleton of the web application It does nothing more than to server a single page that does nothing interesting. This time i do not use a router. Instead, i am trying out a technique i have seen in an article[0] that i have tried in other, smaller, projects and seems to work surprisingly well: it just “cuts off” the URI path by path, passing the request from handler to handler until it finds its way to a handler that actually serves the request. That helps to loosen the coupling between the application and lower handlers, and makes dependencies explicit, because i need to pass the locale, company, etc. down instead of storing them in contexts. Let’s see if i do not regret it on a later date. I also made a lot more packages that in Numerus. In Numerus i actually only have the single pkg package, and it works, kind of, but i notice how i name my methods to avoid clashing instead of using packages for that. That is, instead of pkg.NewApp i now have app.New. Initially i thought that Locale should be inside app, but then there was a circular dependency between app and template. That is why i created a separate package, but now i am wondering if template should be inside app too, but then i would have app.MustRenderTemplate instead of template.MustRender. The CSS is the most bare-bones file i could write because i am focusing in markup right now; Oriol will fill in the file once the application is working. [0]: https://blog.merovius.de/posts/2017-06-18-how-not-to-use-an-http-router/
2023-07-22 22:11:00 +00:00
return handler
}
func (h *App) ServeHTTP(w http.ResponseWriter, r *http.Request) {
Add the logout button Conceptually, to logout we have to “delete the session”, thus the best HTTP verb would be `DELETE`. However, there is no way to send a `DELETE` request with a regular HTML form, and it seems that never will be[0]. I could use a POST, optionally with a “method override” technique, but i was planing to use HTMx anyway, so this was as good an opportunity to include it as any. In this application i am not concerned with people not having JavaScript enabled, because it is for a customer that has a known environment, and we do not have much time anyway. Therefore, i opted to forgo progressive enhancement in cases like this: if `DELETE` is needed, use `hx-delete`. Unfortunately, i can not use a <form> with a hidden <input> for the CSRF token, because `DELETE` requests do not have body and the value should be added as query parameters, like a form with GET method, but HTMx does the incorrect thing here: sends the values in the request’s body. That’s why i have to use a custom header and the `hx-header` directive to include the CSRF token. Then, by default HTMx targets the triggered element for swap with the response from the server, but after a logout i want to redirect the user to the login form again. I could set the hx-target to button to replace the whole body, or tell the client to redirect to the new location. I actually do not know which one is “better”. Maybe the hx-target is best because then everything is handled by the client, but in the case of logout, since it is possible that i might want to load scripts only for logged-in users in the future, i opted for the full page reload. However, HTMx does not want to reload a page that return HTTP 401, hence i had to include the GET method to /login in order to return the login form with a response of HTTP 200, which also helps when reloading in the browser after a failed login attempt. I am not worried with the HTTP 401 when attempting to load a page as guest, because this request most probably comes from the browser, not HTMx, and it will show the login form as intended—even though it is not compliant, since it does not return the WWW-Authenticate header, but this is the best i can do given that no cookie-based authentication method has been accepted[1]. [0]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671#c16 [1]: https://datatracker.ietf.org/doc/id/draft-broyer-http-cookie-auth-00.html
2023-07-26 11:49:47 +00:00
requestPath := r.URL.Path
Add the skeleton of the web application It does nothing more than to server a single page that does nothing interesting. This time i do not use a router. Instead, i am trying out a technique i have seen in an article[0] that i have tried in other, smaller, projects and seems to work surprisingly well: it just “cuts off” the URI path by path, passing the request from handler to handler until it finds its way to a handler that actually serves the request. That helps to loosen the coupling between the application and lower handlers, and makes dependencies explicit, because i need to pass the locale, company, etc. down instead of storing them in contexts. Let’s see if i do not regret it on a later date. I also made a lot more packages that in Numerus. In Numerus i actually only have the single pkg package, and it works, kind of, but i notice how i name my methods to avoid clashing instead of using packages for that. That is, instead of pkg.NewApp i now have app.New. Initially i thought that Locale should be inside app, but then there was a circular dependency between app and template. That is why i created a separate package, but now i am wondering if template should be inside app too, but then i would have app.MustRenderTemplate instead of template.MustRender. The CSS is the most bare-bones file i could write because i am focusing in markup right now; Oriol will fill in the file once the application is working. [0]: https://blog.merovius.de/posts/2017-06-18-how-not-to-use-an-http-router/
2023-07-22 22:11:00 +00:00
var head string
head, r.URL.Path = shiftPath(r.URL.Path)
Add favicon Closes #8.
2023-07-26 16:59:17 +00:00
switch head {
case "static":
Add the skeleton of the web application It does nothing more than to server a single page that does nothing interesting. This time i do not use a router. Instead, i am trying out a technique i have seen in an article[0] that i have tried in other, smaller, projects and seems to work surprisingly well: it just “cuts off” the URI path by path, passing the request from handler to handler until it finds its way to a handler that actually serves the request. That helps to loosen the coupling between the application and lower handlers, and makes dependencies explicit, because i need to pass the locale, company, etc. down instead of storing them in contexts. Let’s see if i do not regret it on a later date. I also made a lot more packages that in Numerus. In Numerus i actually only have the single pkg package, and it works, kind of, but i notice how i name my methods to avoid clashing instead of using packages for that. That is, instead of pkg.NewApp i now have app.New. Initially i thought that Locale should be inside app, but then there was a circular dependency between app and template. That is why i created a separate package, but now i am wondering if template should be inside app too, but then i would have app.MustRenderTemplate instead of template.MustRender. The CSS is the most bare-bones file i could write because i am focusing in markup right now; Oriol will fill in the file once the application is working. [0]: https://blog.merovius.de/posts/2017-06-18-how-not-to-use-an-http-router/
2023-07-22 22:11:00 +00:00
h.fileHandler.ServeHTTP(w, r)
Add favicon Closes #8.
2023-07-26 16:59:17 +00:00
case "favicon.ico":
r.URL.Path = requestPath
h.fileHandler.ServeHTTP(w, r)
default:
Get user from database based on cookie and serve login if not logged in To get the user from the database i have to set the cookie first, that was already done in database.MustAcquire, but i thought they were too far apart, even thought they are so related. So, the cookie, and thus the role, is set when getting the user, that is actually the first thing to do once the connection is acquired. However, that way the database package has no knowledge of cookies, and the code that sets the cookie and retrieves the user are next to each other. I applied the same logic to the changes of locale.Match: it has not business knowing that the accept language string comes from a request; it only needs the actual string. Also, the TODO comment about getting the user’s locale made no sense, now, because app already knows that locale, so there is no need to pass the user to the locale package. Getting the locale is done after retrieving the user from the database, for the same reason the connection is Acquired as far up as possible: almost every request will need this value, together with the user and the database connection. I am a bit affraid that i will end up with functions that always expect these three values. Maybe i can put the locale inside user, as it is the user’s locale, after all, no matter if it came from the database or the user agent, but connection and user must be separate, i think. We’ll see.
2023-07-25 23:50:39 +00:00
conn, err := h.db.Acquire(r.Context())
if err != nil {
panic(err)
}
Acquire the database connection in App.ServeHTTP with cookie set Almost all request will need the database connection, either because they will perform queries or because they need to check if the user is logged in, for instance, so it should be acquired as far above as possible to avoid acquiring multiple connections. This is specially true since i have to pass the cookie to the database to switch role and set request.user.email and request.user.cookie config variables. I do not want to do that many times per request.
2023-07-25 22:48:58 +00:00
defer conn.Release()
Include the locale inside the User struct The locale is completely dependent on the user, as much as its email or CSRF token, so it does not make much sense to have it in a separate variable: for different users we might have to use different locales. Also, this means one less variable to pass to handlers, that most of them will need the user at some point or another (i.e., to render its profile icon). The thing is that i can not import `app.User` from the template package because it would create an import cycle. I created the `auth` package just because of that. I thought that the login code would be better moved to the auth package as well, but of course then i would reintroduce the import cycle between auth and template.
2023-07-26 10:08:59 +00:00
user, err := h.getUser(r, conn)
Get user from database based on cookie and serve login if not logged in To get the user from the database i have to set the cookie first, that was already done in database.MustAcquire, but i thought they were too far apart, even thought they are so related. So, the cookie, and thus the role, is set when getting the user, that is actually the first thing to do once the connection is acquired. However, that way the database package has no knowledge of cookies, and the code that sets the cookie and retrieves the user are next to each other. I applied the same logic to the changes of locale.Match: it has not business knowing that the accept language string comes from a request; it only needs the actual string. Also, the TODO comment about getting the user’s locale made no sense, now, because app already knows that locale, so there is no need to pass the user to the locale package. Getting the locale is done after retrieving the user from the database, for the same reason the connection is Acquired as far up as possible: almost every request will need this value, together with the user and the database connection. I am a bit affraid that i will end up with functions that always expect these three values. Maybe i can put the locale inside user, as it is the user’s locale, after all, no matter if it came from the database or the user agent, but connection and user must be separate, i think. We’ll see.
2023-07-25 23:50:39 +00:00
if err != nil {
panic(err)
}
Acquire the database connection in App.ServeHTTP with cookie set Almost all request will need the database connection, either because they will perform queries or because they need to check if the user is logged in, for instance, so it should be acquired as far above as possible to avoid acquiring multiple connections. This is specially true since i have to pass the cookie to the database to switch role and set request.user.email and request.user.cookie config variables. I do not want to do that many times per request.
2023-07-25 22:48:58 +00:00
if head == "login" {
switch r.Method {
Add the logout button Conceptually, to logout we have to “delete the session”, thus the best HTTP verb would be `DELETE`. However, there is no way to send a `DELETE` request with a regular HTML form, and it seems that never will be[0]. I could use a POST, optionally with a “method override” technique, but i was planing to use HTMx anyway, so this was as good an opportunity to include it as any. In this application i am not concerned with people not having JavaScript enabled, because it is for a customer that has a known environment, and we do not have much time anyway. Therefore, i opted to forgo progressive enhancement in cases like this: if `DELETE` is needed, use `hx-delete`. Unfortunately, i can not use a <form> with a hidden <input> for the CSRF token, because `DELETE` requests do not have body and the value should be added as query parameters, like a form with GET method, but HTMx does the incorrect thing here: sends the values in the request’s body. That’s why i have to use a custom header and the `hx-header` directive to include the CSRF token. Then, by default HTMx targets the triggered element for swap with the response from the server, but after a logout i want to redirect the user to the login form again. I could set the hx-target to button to replace the whole body, or tell the client to redirect to the new location. I actually do not know which one is “better”. Maybe the hx-target is best because then everything is handled by the client, but in the case of logout, since it is possible that i might want to load scripts only for logged-in users in the future, i opted for the full page reload. However, HTMx does not want to reload a page that return HTTP 401, hence i had to include the GET method to /login in order to return the login form with a response of HTTP 200, which also helps when reloading in the browser after a failed login attempt. I am not worried with the HTTP 401 when attempting to load a page as guest, because this request most probably comes from the browser, not HTMx, and it will show the login form as intended—even though it is not compliant, since it does not return the WWW-Authenticate header, but this is the best i can do given that no cookie-based authentication method has been accepted[1]. [0]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671#c16 [1]: https://datatracker.ietf.org/doc/id/draft-broyer-http-cookie-auth-00.html
2023-07-26 11:49:47 +00:00
case http.MethodGet:
serveLoginForm(w, r, user, "/")
Acquire the database connection in App.ServeHTTP with cookie set Almost all request will need the database connection, either because they will perform queries or because they need to check if the user is logged in, for instance, so it should be acquired as far above as possible to avoid acquiring multiple connections. This is specially true since i have to pass the cookie to the database to switch role and set request.user.email and request.user.cookie config variables. I do not want to do that many times per request.
2023-07-25 22:48:58 +00:00
case http.MethodPost:
Include the locale inside the User struct The locale is completely dependent on the user, as much as its email or CSRF token, so it does not make much sense to have it in a separate variable: for different users we might have to use different locales. Also, this means one less variable to pass to handlers, that most of them will need the user at some point or another (i.e., to render its profile icon). The thing is that i can not import `app.User` from the template package because it would create an import cycle. I created the `auth` package just because of that. I thought that the login code would be better moved to the auth package as well, but of course then i would reintroduce the import cycle between auth and template.
2023-07-26 10:08:59 +00:00
handleLogin(w, r, user, conn)
Acquire the database connection in App.ServeHTTP with cookie set Almost all request will need the database connection, either because they will perform queries or because they need to check if the user is logged in, for instance, so it should be acquired as far above as possible to avoid acquiring multiple connections. This is specially true since i have to pass the cookie to the database to switch role and set request.user.email and request.user.cookie config variables. I do not want to do that many times per request.
2023-07-25 22:48:58 +00:00
default:
Add the logout button Conceptually, to logout we have to “delete the session”, thus the best HTTP verb would be `DELETE`. However, there is no way to send a `DELETE` request with a regular HTML form, and it seems that never will be[0]. I could use a POST, optionally with a “method override” technique, but i was planing to use HTMx anyway, so this was as good an opportunity to include it as any. In this application i am not concerned with people not having JavaScript enabled, because it is for a customer that has a known environment, and we do not have much time anyway. Therefore, i opted to forgo progressive enhancement in cases like this: if `DELETE` is needed, use `hx-delete`. Unfortunately, i can not use a <form> with a hidden <input> for the CSRF token, because `DELETE` requests do not have body and the value should be added as query parameters, like a form with GET method, but HTMx does the incorrect thing here: sends the values in the request’s body. That’s why i have to use a custom header and the `hx-header` directive to include the CSRF token. Then, by default HTMx targets the triggered element for swap with the response from the server, but after a logout i want to redirect the user to the login form again. I could set the hx-target to button to replace the whole body, or tell the client to redirect to the new location. I actually do not know which one is “better”. Maybe the hx-target is best because then everything is handled by the client, but in the case of logout, since it is possible that i might want to load scripts only for logged-in users in the future, i opted for the full page reload. However, HTMx does not want to reload a page that return HTTP 401, hence i had to include the GET method to /login in order to return the login form with a response of HTTP 200, which also helps when reloading in the browser after a failed login attempt. I am not worried with the HTTP 401 when attempting to load a page as guest, because this request most probably comes from the browser, not HTMx, and it will show the login form as intended—even though it is not compliant, since it does not return the WWW-Authenticate header, but this is the best i can do given that no cookie-based authentication method has been accepted[1]. [0]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671#c16 [1]: https://datatracker.ietf.org/doc/id/draft-broyer-http-cookie-auth-00.html
2023-07-26 11:49:47 +00:00
methodNotAllowed(w, r, http.MethodPost, http.MethodGet)
Acquire the database connection in App.ServeHTTP with cookie set Almost all request will need the database connection, either because they will perform queries or because they need to check if the user is logged in, for instance, so it should be acquired as far above as possible to avoid acquiring multiple connections. This is specially true since i have to pass the cookie to the database to switch role and set request.user.email and request.user.cookie config variables. I do not want to do that many times per request.
2023-07-25 22:48:58 +00:00
}
} else {
Get user from database based on cookie and serve login if not logged in To get the user from the database i have to set the cookie first, that was already done in database.MustAcquire, but i thought they were too far apart, even thought they are so related. So, the cookie, and thus the role, is set when getting the user, that is actually the first thing to do once the connection is acquired. However, that way the database package has no knowledge of cookies, and the code that sets the cookie and retrieves the user are next to each other. I applied the same logic to the changes of locale.Match: it has not business knowing that the accept language string comes from a request; it only needs the actual string. Also, the TODO comment about getting the user’s locale made no sense, now, because app already knows that locale, so there is no need to pass the user to the locale package. Getting the locale is done after retrieving the user from the database, for the same reason the connection is Acquired as far up as possible: almost every request will need this value, together with the user and the database connection. I am a bit affraid that i will end up with functions that always expect these three values. Maybe i can put the locale inside user, as it is the user’s locale, after all, no matter if it came from the database or the user agent, but connection and user must be separate, i think. We’ll see.
2023-07-25 23:50:39 +00:00
if !user.LoggedIn {
Add the logout button Conceptually, to logout we have to “delete the session”, thus the best HTTP verb would be `DELETE`. However, there is no way to send a `DELETE` request with a regular HTML form, and it seems that never will be[0]. I could use a POST, optionally with a “method override” technique, but i was planing to use HTMx anyway, so this was as good an opportunity to include it as any. In this application i am not concerned with people not having JavaScript enabled, because it is for a customer that has a known environment, and we do not have much time anyway. Therefore, i opted to forgo progressive enhancement in cases like this: if `DELETE` is needed, use `hx-delete`. Unfortunately, i can not use a <form> with a hidden <input> for the CSRF token, because `DELETE` requests do not have body and the value should be added as query parameters, like a form with GET method, but HTMx does the incorrect thing here: sends the values in the request’s body. That’s why i have to use a custom header and the `hx-header` directive to include the CSRF token. Then, by default HTMx targets the triggered element for swap with the response from the server, but after a logout i want to redirect the user to the login form again. I could set the hx-target to button to replace the whole body, or tell the client to redirect to the new location. I actually do not know which one is “better”. Maybe the hx-target is best because then everything is handled by the client, but in the case of logout, since it is possible that i might want to load scripts only for logged-in users in the future, i opted for the full page reload. However, HTMx does not want to reload a page that return HTTP 401, hence i had to include the GET method to /login in order to return the login form with a response of HTTP 200, which also helps when reloading in the browser after a failed login attempt. I am not worried with the HTTP 401 when attempting to load a page as guest, because this request most probably comes from the browser, not HTMx, and it will show the login form as intended—even though it is not compliant, since it does not return the WWW-Authenticate header, but this is the best i can do given that no cookie-based authentication method has been accepted[1]. [0]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671#c16 [1]: https://datatracker.ietf.org/doc/id/draft-broyer-http-cookie-auth-00.html
2023-07-26 11:49:47 +00:00
w.WriteHeader(http.StatusUnauthorized)
serveLoginForm(w, r, user, requestPath)
Get user from database based on cookie and serve login if not logged in To get the user from the database i have to set the cookie first, that was already done in database.MustAcquire, but i thought they were too far apart, even thought they are so related. So, the cookie, and thus the role, is set when getting the user, that is actually the first thing to do once the connection is acquired. However, that way the database package has no knowledge of cookies, and the code that sets the cookie and retrieves the user are next to each other. I applied the same logic to the changes of locale.Match: it has not business knowing that the accept language string comes from a request; it only needs the actual string. Also, the TODO comment about getting the user’s locale made no sense, now, because app already knows that locale, so there is no need to pass the user to the locale package. Getting the locale is done after retrieving the user from the database, for the same reason the connection is Acquired as far up as possible: almost every request will need this value, together with the user and the database connection. I am a bit affraid that i will end up with functions that always expect these three values. Maybe i can put the locale inside user, as it is the user’s locale, after all, no matter if it came from the database or the user agent, but connection and user must be separate, i think. We’ll see.
2023-07-25 23:50:39 +00:00
return
}
Acquire the database connection in App.ServeHTTP with cookie set Almost all request will need the database connection, either because they will perform queries or because they need to check if the user is logged in, for instance, so it should be acquired as far above as possible to avoid acquiring multiple connections. This is specially true since i have to pass the cookie to the database to switch role and set request.user.email and request.user.cookie config variables. I do not want to do that many times per request.
2023-07-25 22:48:58 +00:00
switch head {
Add the logout button Conceptually, to logout we have to “delete the session”, thus the best HTTP verb would be `DELETE`. However, there is no way to send a `DELETE` request with a regular HTML form, and it seems that never will be[0]. I could use a POST, optionally with a “method override” technique, but i was planing to use HTMx anyway, so this was as good an opportunity to include it as any. In this application i am not concerned with people not having JavaScript enabled, because it is for a customer that has a known environment, and we do not have much time anyway. Therefore, i opted to forgo progressive enhancement in cases like this: if `DELETE` is needed, use `hx-delete`. Unfortunately, i can not use a <form> with a hidden <input> for the CSRF token, because `DELETE` requests do not have body and the value should be added as query parameters, like a form with GET method, but HTMx does the incorrect thing here: sends the values in the request’s body. That’s why i have to use a custom header and the `hx-header` directive to include the CSRF token. Then, by default HTMx targets the triggered element for swap with the response from the server, but after a logout i want to redirect the user to the login form again. I could set the hx-target to button to replace the whole body, or tell the client to redirect to the new location. I actually do not know which one is “better”. Maybe the hx-target is best because then everything is handled by the client, but in the case of logout, since it is possible that i might want to load scripts only for logged-in users in the future, i opted for the full page reload. However, HTMx does not want to reload a page that return HTTP 401, hence i had to include the GET method to /login in order to return the login form with a response of HTTP 200, which also helps when reloading in the browser after a failed login attempt. I am not worried with the HTTP 401 when attempting to load a page as guest, because this request most probably comes from the browser, not HTMx, and it will show the login form as intended—even though it is not compliant, since it does not return the WWW-Authenticate header, but this is the best i can do given that no cookie-based authentication method has been accepted[1]. [0]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671#c16 [1]: https://datatracker.ietf.org/doc/id/draft-broyer-http-cookie-auth-00.html
2023-07-26 11:49:47 +00:00
case "me":
profileHandler(user, conn)(w, r)
Acquire the database connection in App.ServeHTTP with cookie set Almost all request will need the database connection, either because they will perform queries or because they need to check if the user is logged in, for instance, so it should be acquired as far above as possible to avoid acquiring multiple connections. This is specially true since i have to pass the cookie to the database to switch role and set request.user.email and request.user.cookie config variables. I do not want to do that many times per request.
2023-07-25 22:48:58 +00:00
case "":
switch r.Method {
case http.MethodGet:
Include the locale inside the User struct The locale is completely dependent on the user, as much as its email or CSRF token, so it does not make much sense to have it in a separate variable: for different users we might have to use different locales. Also, this means one less variable to pass to handlers, that most of them will need the user at some point or another (i.e., to render its profile icon). The thing is that i can not import `app.User` from the template package because it would create an import cycle. I created the `auth` package just because of that. I thought that the login code would be better moved to the auth package as well, but of course then i would reintroduce the import cycle between auth and template.
2023-07-26 10:08:59 +00:00
h.serveDashboard(w, r, user)
Acquire the database connection in App.ServeHTTP with cookie set Almost all request will need the database connection, either because they will perform queries or because they need to check if the user is logged in, for instance, so it should be acquired as far above as possible to avoid acquiring multiple connections. This is specially true since i have to pass the cookie to the database to switch role and set request.user.email and request.user.cookie config variables. I do not want to do that many times per request.
2023-07-25 22:48:58 +00:00
default:
methodNotAllowed(w, r, http.MethodGet)
}
default:
http.NotFound(w, r)
}
Add the skeleton of the web application It does nothing more than to server a single page that does nothing interesting. This time i do not use a router. Instead, i am trying out a technique i have seen in an article[0] that i have tried in other, smaller, projects and seems to work surprisingly well: it just “cuts off” the URI path by path, passing the request from handler to handler until it finds its way to a handler that actually serves the request. That helps to loosen the coupling between the application and lower handlers, and makes dependencies explicit, because i need to pass the locale, company, etc. down instead of storing them in contexts. Let’s see if i do not regret it on a later date. I also made a lot more packages that in Numerus. In Numerus i actually only have the single pkg package, and it works, kind of, but i notice how i name my methods to avoid clashing instead of using packages for that. That is, instead of pkg.NewApp i now have app.New. Initially i thought that Locale should be inside app, but then there was a circular dependency between app and template. That is why i created a separate package, but now i am wondering if template should be inside app too, but then i would have app.MustRenderTemplate instead of template.MustRender. The CSS is the most bare-bones file i could write because i am focusing in markup right now; Oriol will fill in the file once the application is working. [0]: https://blog.merovius.de/posts/2017-06-18-how-not-to-use-an-http-router/
2023-07-22 22:11:00 +00:00
}
}
}
Get user from database based on cookie and serve login if not logged in To get the user from the database i have to set the cookie first, that was already done in database.MustAcquire, but i thought they were too far apart, even thought they are so related. So, the cookie, and thus the role, is set when getting the user, that is actually the first thing to do once the connection is acquired. However, that way the database package has no knowledge of cookies, and the code that sets the cookie and retrieves the user are next to each other. I applied the same logic to the changes of locale.Match: it has not business knowing that the accept language string comes from a request; it only needs the actual string. Also, the TODO comment about getting the user’s locale made no sense, now, because app already knows that locale, so there is no need to pass the user to the locale package. Getting the locale is done after retrieving the user from the database, for the same reason the connection is Acquired as far up as possible: almost every request will need this value, together with the user and the database connection. I am a bit affraid that i will end up with functions that always expect these three values. Maybe i can put the locale inside user, as it is the user’s locale, after all, no matter if it came from the database or the user agent, but connection and user must be separate, i think. We’ll see.
2023-07-25 23:50:39 +00:00
Add profile form, inside a user menu This is the first form that uses HTMx, and can not return a 400 error code because otherwise HTMx does not render the content. Since now there are pages that do not render the whole html, with header and body, i need a different layout for these, and moved the common code to handle forms and such a new template file that both layouts can use. I also need the request in template.MustRender to check which layout i should use. Closes #7.
2023-07-26 18:46:09 +00:00
func (h *App) serveDashboard(w http.ResponseWriter, r *http.Request, user *auth.User) {
template.MustRender(w, r, user, "dashboard.gohtml", nil)
Get user from database based on cookie and serve login if not logged in To get the user from the database i have to set the cookie first, that was already done in database.MustAcquire, but i thought they were too far apart, even thought they are so related. So, the cookie, and thus the role, is set when getting the user, that is actually the first thing to do once the connection is acquired. However, that way the database package has no knowledge of cookies, and the code that sets the cookie and retrieves the user are next to each other. I applied the same logic to the changes of locale.Match: it has not business knowing that the accept language string comes from a request; it only needs the actual string. Also, the TODO comment about getting the user’s locale made no sense, now, because app already knows that locale, so there is no need to pass the user to the locale package. Getting the locale is done after retrieving the user from the database, for the same reason the connection is Acquired as far up as possible: almost every request will need this value, together with the user and the database connection. I am a bit affraid that i will end up with functions that always expect these three values. Maybe i can put the locale inside user, as it is the user’s locale, after all, no matter if it came from the database or the user agent, but connection and user must be separate, i think. We’ll see.
2023-07-25 23:50:39 +00:00
}