Feature: serve multiple domains on a single instance #447
No reviewers
Labels
No labels
A: API
A: Backend
A: Federation
A: Front-End
A: I18N
A: Meta
A: Security
Build
C: Bug
C: Discussion
C: Enhancement
C: Feature
Compatibility
Dependency
Design
Documentation
Good first issue
Help welcome
Mobile
Rendering
S: Blocked
S: Duplicate
S: Incomplete
S: Instance specific
S: Invalid
S: Needs Voting/Discussion
S: Ready for review
Suggestion
S: Voted on Loomio
S: Wontfix
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Plume/Plume#447
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "feat/custom-domains"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This Pull Request addresses #94.
We start by adding
custom_domain
to theblogs
table.Blogs with custom domains have special routes with higher priority, but administrative routes will remain on the instance host.
Domain administration is left to the user (and/or admin)
(but we might be able to provide a check on whether it's already correctly configured)
Codecov Report
after taking a break to work on refactoring with Clippy (#462) , a lot has happened since:
Meanwhile, a community member has reported, that Plume works via Tor, without any modifications.
Now, adding the custom domain feature, would possibly require modification.
Regardless, we need to rethink our approach to routing…
…and, i could use some help with that.
Here's some of my own thoughts:
Host
would need to become an arrayA closing summary: it would be nice if route functions with
custom_domains: Host(s)
were automatically ranked higher, otherwise, we'd need to split the mounting of routes into: known-domains / unknown or default domain.some thoughts, after a long hiatus
@ -0,0 +1,2 @@
-- Adding custom domain to Blog as an optional field
ALTER TABLE blogs ADD COLUMN custom_domain VARCHAR DEFAULT NULL UNIQUE;
we should also verify no one is trying to su their
custom_domain
to our instance domainbtw, i was wondering if this should be an array, and i've come to the conclusion that it should most definitely not be one
okay, so before we mount anything, we need to
select custom_domain from blogs
and perhaps cache that on startupif that is empty, we proceed like before, if it's not we should route into into our custom routes
the problem is, that we cannot extract the host header (or any header) before we are in a route functions, because that's where all of rocket's main functionality happens, so we need to think of something
@ -20,2 +20,4 @@
use template_utils::Ructe;
#[get("/?<page>", rank = 2)]
pub fn custom_details(
many routes will need duplicated functions, and reordering
in all those cases, we should replace the actual guts of the function with a private one, and all it, once the parameters have been processed successfully
as I said (a very long time ago), we could use a Fairing to modify the path from
https://somesite.com/something/idkwhat
to(https://...)/custom_domain/somesite.com/something/idkwhat
. I think this is the easiest way to do it, the other being to have to reorder each route and add a guard that extract the custom domain of current request, if custom domain there is (like the Host struct, but with an additional check to return forward when it's not a known custom domain)you did, and i'm still not sure i follow this
let's make a concrete example here:
i have a blog (Words words words) with a custom_domain (https://words.eena.me/) on the instance https://blogs.igalic.co (so, https://blogs.igalic.co/~/words/)
someone makes a request for https://words.eena.me/
what do they see in their browser's URL bar?
what happens in our code?
someone makes a request for https://blogs.igalic.co/~/words/
here, i'm expecting a redirect to https://words.eena.me/
is this what happens, or do we have to do anything special?
thank you very much for your reply, btw, and for your patience
What they see in their url bar : https://words.eena.me/ (unchanged)
What happens in our code : it's treated as
/custom_domain/words.eena.me/
(or anything actually, even/~/words/
if we want. In a Fairing, we have the host header, the (mutable) request path and access to the database, the sky's the limit)Someone makes a request for https://blogs.igalic.co/~/words/ , this change nothing. If we want it to redirect to https://words.eena.me/, we have to implement it
Also, made me think that as we use absolute urls, most links could be broken, depending on how the Fairing is made exactly (just concatenating path versus trying to understand them a bit)
Pull request closed