| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
content_type is now optional; if not specified, it will remain
empty. `application/octet-stream` will be put on read in the
frontend.
Length is now represented as NonZeroUsize - why would you upload a
zero-byte file when you can just conjure one from the void whenever
you need one? This should save me a little bit of memory.
Representing content_type as a typed MIME value would be the next
logical step.
|
| |
|
|
|
|
|
| |
It turns out that BufWriter requires calling `flush()` manually and
doesn't do it on `drop()`. I forgot about that.
|
| |
|
|
|
|
|
|
| |
This requires the `axum` feature to be enabled, to prevent unwanted
dependencies (e.g. in client apps or when using a different framework,
since the library doesn't concern itself with I/O)
|
|
|
|
|
| |
Client ID and the redirect URI must match those that were used to
create the grant.
|
|
|
|
|
| |
This may help non-IndieAuth-aware clients to integrate better into the
flow.
|
|
|
|
|
|
|
| |
`kittybox_indieauth::Error` now represents errors in the IndieAuth
process itself. `IndieAuthError` got renamed to `ResourceErrorKind` to
reflect errors that a resource server (i.e. IndieAuth consumer) might
return to a client who somehow didn't authorize themselves properly.
|
|
|
|
|
|
|
|
|
| |
This will allow to display a prettier error page in the future.
There is a possibility of instantiating the panic handler per-module
to allow for custom panic messages expressed in the same form the
module itself gives error messages (e.g. pretty HTML for frontend,
MicropubError for Micropub messages etc.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the living, breathing proof that Kittybox can be split into
independent components without sacrificing any functionality. Just
make sure all neccesary backing storage components are available to
the modules that need them.
Also the Micropub client was split into several files, because it's
about to get much bigger and more full-featured.
Yes, I am going to write it in vanilla JavaScript. I don't trust
anything from NPM to run on my computer. Not anymore. Not after the
node-ipc malware fiasco. And I am definitely not going to spin up a VM
or a Docker container (who uses Docker containers as a security
measure?) to hack on my own code.
Cargo can at least be sandboxed inside Nix, where it can't do much
harm. NPM basically requires unrestricted network access to download
dependencies, and it runs arbitrary code upon **downloading**
them. Cargo and rust-analyzer, on the other hand, can be configured to
not trust the source code and its dependencies (for example, Cargo
doesn't execute code on fetching dependencies - only on building, and
rust-analyzer's proc-macro expansion support can be sacrificed for
more security).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Some kittybox-indieauth crate bugs were fixed
- Things should mostly work...
- ...if you somehow supply your own backend store
- YES I MADE IT MODULAR AGAIN
- NO I AM NOT SORRY
- YOU WILL THANK ME LATER
- DO NOT DENY THE HEAVENLY GIFT OF GENERICS IN RUST
- Retrieving profiles doesn't work for now because I am unsure how to
implement it best
|
|
|
|
|
|
| |
Really, it should be `Either<AuthorizationRequest, GrantRequest>` but
either serde or axum got iffy about me deserializing it from a
form. Not sure which one.
|
|
|
|
|
|
|
|
|
| |
This makes converting Option<TokenData> into a response and vice versa
a breeze, and hide the complexity of TokenIntrospectionResponse forced
upon this library by the IndieAuth standard.
Really, this type should've been represented as Option<TokenData>, I
just don't know how to add the "active" field to it properly.
|
|
|
|
| |
It looks like buffering reads can double my performance. Nice.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Turns out it was comparing the list of required scopes
with **itself**. Oops, that's a major security issue.
|
|
|
|
|
|
|
|
|
|
| |
This crate is the base framework-agnostic implementation of all data
structures and methods required for IndieAuth protocol. Anything that
can deserialize HTTP request payloads with serde can utilize this
crate.
This is a good candidate to independently release on crates.io when
the interface becomes stable enough.
|
|
|
|
|
| |
I'm afraid this might've caused me to do some weird stuff with the
tempdir. Better do it like this.
|
|
|
|
| |
On query parsing error, this will return a MicropubError.
|
|
|
|
|
| |
Looks like this shared data structure will be useful to me later when
splitting off the media endpoint into its own crate.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This frees up the name for the future in-house IndieAuth
implementation and also clarifies the purpose of this module.
Its future is uncertain - most probably when the token endpoint gets
finished, it will transform into a way to query that token
endpoint. But then, the media endpoint also depends on it, so I might
have to copy that implementation (that queries an external token
endpoint) and make it generic enough so I could both query an external
endpoint or use internal data.
|
|
|
|
|
|
|
|
|
|
| |
Supported features:
- Streaming upload
- Content-addressed storage
- Metadata
- MIME type (taken from Content-Type)
- Length (I could use stat() for this one tho)
- filename (for Content-Disposition: attachment, WIP)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Axum has streaming bodies and allows to write simpler code. It also
helps enforce stronger types and looks much more neat.
This allows me to progress on the media endpoint and add streaming
reads and writes to the MediaStore trait.
Metrics are temporarily not implemented. Everything else was
preserved, and the tests still pass, after adjusting for new calling
conventions.
TODO: create method routers for protocol endpoints
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Flake lock file updates:
• Updated input 'flake-utils':
'github:numtide/flake-utils/f7e004a55b120c02ecb6219596820fcd32ca8772' (2021-06-16)
→ 'github:numtide/flake-utils/7e2a3b3dfd9af950a856d66b0a7d01e3c18aa249' (2022-07-04)
• Updated input 'naersk':
'github:nmattia/naersk/f21309b38e1da0d61b881b6b6d41b81c1aed4e1d' (2022-05-03)
→ 'github:nmattia/naersk/cddffb5aa211f50c4b8750adbec0bbbdfb26bb9f' (2022-06-12)
• Updated input 'nixpkgs':
'github:nixos/nixpkgs/dfd82985c273aac6eced03625f454b334daae2e8' (2022-05-20)
→ 'github:nixos/nixpkgs/71a4f0dc3d80ba76f437c888c1c3d59f1df98163' (2022-07-05)
|
|
|
|
|
| |
Actually got the idea from https://xeiaso.net/, who groups xer
website's endpoints under the `.within` folder.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Kittybox's source code is moved to a subfolder
- This improves build caching by Nix since it doesn't take changes
to other files into account
- Package and test definitions were spun into separate files
- This makes my flake.nix much easier to navigate
- This also makes it somewhat possible to use without flakes (but
it is still not easy, so use flakes!)
- Some attributes were moved in compliance with Nix 2.8's changes to
flake schema
|
| |
|
|
|
|
|
|
|
|
| |
Flake lock file updates:
• Updated input 'nixpkgs':
'github:vikanezrimaya/nixpkgs/bf819aeeb2f0954506a748ff117962edc8cf732d' (2022-03-28)
→ 'github:nixos/nixpkgs/dfd82985c273aac6eced03625f454b334daae2e8' (2022-05-20)
|
|
|
|
|
|
|
|
|
|
|
| |
I said some boastful words about Kittybox being able to horizontally
scale and I wanted to prove them. This is the proof.
This test creates an NFS file server, then spawns three
VMs. Provisioning a website on one of them, it then queries the
website on all of the three machines. This shows that a shared backing
store can make Kittybox infinitely scale horizontally depending on how
much traffic you're getting.
|
| |
|
|
|
|
|
|
|
|
| |
This bit of code is still disabled for now though. I need to actually
gather and render facepiles.
Additionally, now details won't even show if there were no reactions
to the post, which saves space.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They really use the same framework, so for now a unit test for like
posts is sufficient. Of course, for proper coverage, one can introduce
tests for bookmarks too, especially if one chooses to render them
differently. The logic will be pretty much the same though.
Replies might use the same logic, since those are also
Webmention-oriented posts.
(It looks like another way to classify MF2 documents is slowly forming
in my brain. Maybe I should write about it on my blog.)
|
|
|
|
|
|
|
| |
There were lots of unneccesary Option::unwrap() invocations that could
be replaced with `if let` statements. This makes the code cleaner and
less likely to panic in case a corrupted, incomplete or manually
injected MF2-JSON document needs to be rendered.
|
|
|
|
| |
Now everyone will know where to get my software if they see it.
|
|
|
|
|
|
| |
It mostly checks the same old things as with notes, but does check for
a name (and as it's explicitly provided, it does work with the buggy
version of the `microformats` crate.
|
|
|
|
|
|
|
|
|
|
| |
New generators include:
- Articles (h-entry with a name)
- Replies (notes with an in-reply-to)
- Likes (h-entries with a like-of)
For replies and likes, there are variants with an h-cite (full reply
context) or a link (partial reply context).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These unit tests generate a random MF2-JSON post, convert it to
MF2-HTML using the template and then read it back using the
`microformats` crate.
The only problem is that it has a nasty bug with overstuffing implied
properties. This is being worked on:
https://gitlab.com/maxburon/microformats-parser/-/issues/7
For now the tests marked as ignored because they fail. But the
function itself that generates them should remain here for
documentation and potential code sharing with the `microformats`
crate, potentially even migrating to a subcrate there.
|
| |
|
|
|
|
|
|
|
| |
These features share some code since they both require fetching reply
contexts, so it makes sense to implement them together.
TODO cover webmention sending with integration tests
|