Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: serve multiple domains on a single instance #447

Closed
wants to merge 5 commits into from
Closed

Feature: serve multiple domains on a single instance #447

wants to merge 5 commits into from

Conversation

igalic
Copy link
Contributor

@igalic igalic commented Feb 23, 2019

This Pull Request addresses #94.
We start by adding custom_domain to the blogs 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)

@elegaanz elegaanz added C: Feature This is a new feature S: Incomplete This PR is not complete yet A: Backend Code running on the server labels Feb 23, 2019
@codecov
Copy link

codecov bot commented Feb 23, 2019

Codecov Report

Merging #447 into master will decrease coverage by 2.04%.
The diff coverage is 2.32%.

@@            Coverage Diff             @@
##           master     #447      +/-   ##
==========================================
- Coverage   26.89%   24.84%   -2.05%     
==========================================
  Files          65       64       -1     
  Lines        8966     6375    -2591     
==========================================
- Hits         2411     1584     -827     
+ Misses       6555     4791    -1764

@elegaanz elegaanz added this to the 1.0 milestone Mar 12, 2019
igalic added 5 commits March 24, 2019 11:57
since we know of no one who uses SQLite in prod, we can probably just
fix this on the fly.
and use it in a specialised FromRequest, so we can start hooking mount
points in rocket
this is just the start, we'll need to tweak *all* routes…
@igalic
Copy link
Contributor Author

igalic commented Mar 24, 2019

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:

  • The route ranking (alone) feels limiting in that regard.
  • we have two route functions which do the same thing, only slightly different, so this needs some abstraction
  • we have two types of routes: known domain, or default domain (this could would also be taken for unknown domains)
  • to properly map onion domains, the Host would need to become an array

A 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.

@igalic igalic added the Help welcome Extra attention is needed label Mar 24, 2019
Copy link
Contributor Author

@igalic igalic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should also verify no one is trying to su their custom_domain to our instance domain

@@ -137,6 +137,7 @@ Then try to restart Plume
.mount(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay, so before we mount anything, we need to select custom_domain from blogs and perhaps cache that on startup
if 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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

@@ -19,6 +19,38 @@ use plume_models::{
use routes::{errors::ErrorPage, Page, PlumeRocket};
use template_utils::Ructe;

#[get("/?<page>", rank = 2)]
pub fn custom_details(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@@ -49,6 +75,7 @@ pub struct Blog {
pub summary_html: SafeString,
pub icon_id: Option<i32>,
pub banner_id: Option<i32>,
pub custom_domain: Option<String>,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw, i was wondering if this should be an array, and i've come to the conclusion that it should most definitely not be one

@igalic igalic closed this May 24, 2019
@igalic igalic deleted the feat/custom-domains branch May 24, 2019 13:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A: Backend Code running on the server C: Feature This is a new feature Help welcome Extra attention is needed S: Incomplete This PR is not complete yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants