Feature: serve multiple domains on a single instance #447

已關閉
igalic 請求將 5 次程式碼提交從 feat/custom-domains 合併至 master
igalic 已留言 5 年前 (已從 github.com 遷移)

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)

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)
codecov[bot] 已留言 5 年前 (已從 github.com 遷移)

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
# [Codecov](https://codecov.io/gh/Plume-org/Plume/pull/447?src=pr&el=h1) Report > Merging [#447](https://codecov.io/gh/Plume-org/Plume/pull/447?src=pr&el=desc) into [master](https://codecov.io/gh/Plume-org/Plume/commit/bdfad844d7939e757929d1643132a9346f82dd66?src=pr&el=desc) will **decrease** coverage by `2.04%`. > The diff coverage is `2.32%`. ```diff @@ 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 ```
igalic 已留言 5 年前 (已從 github.com 遷移)

after taking a break to work on refactoring with Clippy (#462) , a lot has happened since:

  • Blogs can now be edited, and have banners and icons (#460), quite useful, if your front-page is the blog page!
  • We have a central Config struct (#494)
  • Blogs & Users now have an Fqn field which doesn't need to be recalculated (#457)

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.

after taking a break to work on refactoring with Clippy (#462) , a lot has happened since: - Blogs can now be edited, and have banners and icons (#460), quite useful, if your front-page is the blog page! - We have a central Config struct (#494) - Blogs & Users now have an Fqn field which doesn't need to be recalculated (#457) 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 (已從 github.com 遷移) 已審核 5 年前
igalic (已從 github.com 遷移) 留下了回應

some thoughts, after a long hiatus

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;
igalic (已從 github.com 遷移) 已留言 5 年前

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

we should also verify no one is trying to su their `custom_domain` to our instance domain
igalic (已從 github.com 遷移) 已留言 5 年前

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

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 (已從 github.com 遷移) 已留言 5 年前

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

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
@ -20,2 +20,4 @@
use template_utils::Ructe;
#[get("/?<page>", rank = 2)]
pub fn custom_details(
igalic (已從 github.com 遷移) 已留言 5 年前

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

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
trinity-1686a 已審核 5 年前
擁有者

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)

as I said (a very long time ago), we could use a [Fairing](https://api.rocket.rs/v0.4/rocket/fairing/trait.Fairing.html#method.on_request) 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)
igalic (已從 github.com 遷移) 已審核 5 年前
igalic (已從 github.com 遷移) 已留言 5 年前

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

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
trinity-1686a 已審核 5 年前
擁有者

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)

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)
無法重新開放此合併請求,因為該分支已刪除。
您也可以查看命令列指南

第一步:

在您的儲存庫中切換到新分支並測試變更。
git checkout -b feat/custom-domains master
git pull origin feat/custom-domains

第二步:

合併變更並更新到 Forgejo。
git checkout master
git merge --no-ff feat/custom-domains
git push origin master
登入 才能加入這對話。
沒有審核者
未選擇里程碑
沒有負責人
2 參與者
通知
截止日期
截止日期無效或超出範圍,請使用「yyyy-mm-dd」的格式。

未設定截止日期。

先決條件

未設定先決條件。

參考: Plume/Plume#447
載入中…
尚未有任何內容