| Age | Commit message (Collapse) | Author |
|---|
|
Hadn't tested this when I made it. Was outputting a formatted byte
string instead of the plain base64, which resulted in `b'BASE_64'` being
inserted. Output the real base64 to get the image to decode properly.
|
|
HTML copied from the 404 page, but I remove the `text-center` on the
error message because it doesn't look good. Took a multiline message for
me to realise it.
|
|
The `set_404()` function doesn't do this, as it makes no assumptions
about response content type.
|
|
Base structure copied from `404.html`. Python script based on the
`generate_homebrew_formula.py` script in the main DomeKey repository.
The filename comes from the Apache server configuration.
Generate the 500 page because we can't rely on dependencies. This gets
the CSS and logo and includes them inline in the HTML page.
Thanks to this answer for explaining how to get a byte string from a
file to send to the base64 encoder:
https://stackoverflow.com/questions/45482272/typeerror-a-bytes-like-object-is-required-not-str-python-2-to-3/45482834#45482834
|
|
Match the change in `index.html`.
|
|
The `REQUEST_URI` parameter gives us the URL path including the query
string. Unfortunately, there's no param for just the path without the
query string. Well, that's not entirely true. On my production server
I'll be using Apache, and in development I'm using Lighttpd. Apache
provides a `SCRIPT_URL` param that does include just the path, but
Lighttpd doesn't appear to have an equivalent.
I wasn't able to figure out how to add a `SCRIPT_URL` param in Lighttpd
manually, either. Using `bin-environment` in the FastCGI config didn't
work, and using `setenv.add-environment` wouldn't allow me to set it to
both of our routes (I assume).
In light of this, just grab the path from `REQUEST_URI` by getting the
part in front of `?`.
|
|
The query string is already included in the `REQUEST_URI` param. What we
had would just print it twice.
|
|
|
|
|
|
Want to be able to use our static image and CSS assets from the FCGI
code when rendering HTML.
|
|
|
|
I want to be able to use the exact same logic for the `/license` route.
To do so, we move the common logic to a new `build_response()` function.
For all responses we need to return from `build_response()`, make new
structs `HtmlResponse` and `ZipResponse` that write the response in the
desired format.
The `ZipResponse` does what we're already doing in `/license/download`.
The `HtmlResponse` will respond with HTML and show a thank-you page on
success.
|
|
The script name isn't necessarily the same as the request path. We
really want the request path.
|
|
|
|
|
|
|
|
Respond with a 500 on error.
Add 'aquatic-prime' to `foreign_links` errors to be able to convert it
with `into()`.
|
|
Read https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
recently, and reducing the pool size seemed like a good idea.
|
|
|
|
Will make it a bit easier to handle errors from `Result`s.
|
|
|
|
|
|
Forgot that `include_str!` existed. Certainly makes things a lot cleaner
this way.
|
|
If the purchaser coming from POST params is found in the database,
generate a license for the purchaser, zip the license, and send a
response containing the zipped data.
zip:
Change the writer input to a mutable reference to enable us to use the
zip data when writing to the response. Otherwise we get a borrow error.
|
|
Use POST params `name`, `email`, and `secret` to get a purchaser from
the database.
If none exists, we should probably send a 404, otherwise we'll generate
a license for that purchaser and send it in the response as a Zip
archive.
|
|
|
|
This binary will show a thank-you page to purchasers. I had also planned
to make a third binary to send the license file as a Zip archive, but
now I think I'm going to do that here too, working out the routing
inside this program.
|
|
We want another route for a thank-you page, and a third for a Zip
download of the license.
|
|
This will enable us to use the logging code in other binaries.
|
|
|
|
|
|
Binary to generate a license plist.
|
|
So we can use them from outside the crate.
|
|
Want a `license-generator` binary with a hyphen. Normally I'd name my
Rust files with underscores, but I didn't want to add `[[bin]]` sections
to `Cargo.toml`.
|
|
Want to make another binary to generate license files.
|
|
Makes it stand out a bit differently.
|
|
|
|
It was too blurry.
|
|
Ensure that nothing leaves the viewable page area and that no elements
collide with one another.
|
|
This reverts commit efa10ba02a7e45eae9bbedd134719842a02dfe5c.
Huh, looks like "to bottom" is the correct syntax. I thought it was a
faulty search-and-replace in my editor.
|
|
Not sure how that happened.
|
|
Needed to adjust some positioning styles and fix the padding on the
button.
|
|
Use `.button` only for base button traits.
|
|
* Move Lucida Grande font stack to a variable
* Add buttons styles for a magenta gradiented button
|
|
Like what I did in edf6fceedd9b4169ceb63172c60733ef84d78951 for 500
errors, extract these errors to functions also.
Doesn't give us any gains in terms of reusability like it did before, as
we're only responding with each of these errors once, but it does clean
up the code in the `main()` function a bit.
|
|
Clean up the `main()` function by extracting all these similar lines to
a function.
|
|
Otherwise we get a borrow error:
error[E0373]: closure may outlive the current function, but it borrows `pool`, which is owned by the current function
--> src/main.rs:67:18
|
67 | fastcgi::run(|mut req| {
| ^^^^^^^^^ may outlive borrowed value `pool`
...
123 | let mut cx = match pool.get_conn() {
| ---- `pool` is borrowed here
help: to force the closure to take ownership of `pool` (and any other referenced variables), use the `move` keyword
|
67 | fastcgi::run(move |mut req| {
| ^^^^^^^^^^^^^^
|
|
This way we can ask the pool for a connection on each request instead of
trying to reuse a single connection.
|
|
This currently errors on a borrow problem with the `cx` in the closure.
Here we get the purchaser name and email from the POST params and insert
them as a record in the database.
If all goes well, we respond with a 200. Otherwise we log errors and
respond with 500.
|
|
Move the call to `params::parse()` from `request::verified()` into
`main()`. This enables us to access values from POST params inside the
`main()` function. We'll need this to store purchaser name and email
address.
|
