planetary-social / rooms-frontend

MIT License
4 stars 2 forks source link

Configure aliases as subdomains - nginx/docker #24

Closed rabble closed 1 year ago

rabble commented 1 year ago

This needs someone who knows docker and nginx

Requires:

chereseeriepa commented 1 year ago

https://github.com/planetary-social/rooms-frontend/issues/27 see this. the nginx config will need to route to the chosen route there

chereseeriepa commented 1 year ago

Update: https://github.com/planetary-social/rooms-frontend/issues/27 is merged, we will need to add nginx config to route aliases like https://cherese.civic.love to http://localhost:{PORT}/profile/alias/cherese

boreq commented 1 year ago

This is done for planetary.name as far as I know. Can we get more info about this @chereseeriepa? Is this ticket specifically about civic.love? Can this be closed/should it be blocked?

chereseeriepa commented 1 year ago

I think I remember @mplorentz said this is done manually for planetary.name, this should be done for all rooms. It is blocked because I dont know how to do it

mplorentz commented 1 year ago

The short answer for how to do it comes in two pieces: 1) Some nginx config lines that route all subdomains to the same host as the root domain. A good example of a complete config can be found here. 2) Nginx must serve a wildcard SSL certificate. The example config I linked above does this too. Automatically requesting and renewing the certificate is tricker and something I haven't done before. We have an existing ticket for this: https://github.com/planetary-social/infrastructure/issues/28

chereseeriepa commented 1 year ago

This is needed for civic.love and scuttle.im

cooldracula commented 1 year ago

This is addressed in planetary-social/ansible-scripts #12, though it isn't working fully yet. The config is set, but the flow is not. I suspect it has to do with some routing confusion on my part between what needs to go to the go-ssb-room and what needs to go to the frontend.

chereseeriepa commented 1 year ago

Moving this back to TODO, @cooldracula im not sure if this is resolved or not... possibly could be and just a cert issue. But checking now I cant go to https://cherese.planetary.pro and be shown my profile

If you need input, let me know

cooldracula commented 1 year ago

I do need a bit of help with this! I have a routing configuration set up, but I am not sure how to actually make the aliases to test them. At the moment, when a route is undefined or using the 8008 then nginx pushes it to the go-ssb-room figure out. I am not sure how a client is communicating with planetary.pro to be able to set up aliases or communicate the aliases. With a better understanding of this, I think it will be easier for me to figure out the routing for it.

cooldracula commented 1 year ago

I looked at this with @mplorentz today, and think this may require more discussion, as it may not be a solved problem at the code level.

We were both uncertain how aliases were meant to be handled by the vue router in the front end.

For example: at the moment if you go to https://zach.planetary.pro it will show you my alias information. It's the same page as going to https://planetary.pro/alias/zach. Both are served by go-ssb-room.

If you go to https://planetary.pro/profile/zach, you get an error message that we could not load the profile. I was not sure if this is because it's expecting a feed id instead of an alias, or if it was due to my profile having the opt-out of web publishing toggle set.

What is the expected behaviour for /profile/$alias routes, in terms of vue's routing logic? Does the vue frontend map the alias to the proper feed id through a graphql query or some other method? Or is it needing to communicate to go-ssb-room in some way?

This may be working already, but we'd want to test it with a public user. If not, would y'all be able to elaborate on what's expected on the vue side?

Thank you!

cc: @chereseeriepa @mixmix

chereseeriepa commented 1 year ago

Thanks for taking a look at this, heres my responses to some of the things you mentioned :)

For example: at the moment if you go to https://zach.planetary.pro/ it will show you my alias information. It's the same page as going to https://planetary.pro/alias/zach. Both are served by go-ssb-room.

If you go to https://zach.planetary.pro, it should route to https://planetary.pro/profile/alias/zach which is a route handled by the vue router. https://planetary.pro/alias/zach is the old route (as you mentioned its handled by the go-ssb-room router)

If you go to https://planetary.pro/profile/zach, you get an error message that we could not load the profile.

That is expected because that route takes feedIds not aliases, hence why i made another route /profile/alias/{alias}

What is the expected behaviour for /profile/$alias routes, in terms of vue's routing logic? Does the vue frontend map the alias to the proper feed id through a graphql query or some other method? Or is it needing to communicate to go-ssb-room in some way?

It should be /profile/alias/{alias} routes. It routes the alias to the feedId of that alias using a graphql endpoint: getProfileByAlias(alias) which takes the alias and loads the profile which includes the feedId. getProfileByAlias is defined here and a GET request to go-ssb-room. The expected behaviour is that it should route https://zach.planetary.pro to https://planetary.pro/profile/alias/zach, which will then try and resolve the profile for the alias zach

This may be working already, but we'd want to test it with a public user. If not, would y'all be able to elaborate on what's expected on the vue side?

Everything should be set up and it just needs nginx config to route {alias}.planetary.pro to planetary.pro/profile/alias/{alias}

References:

HTH :)

chereseeriepa commented 1 year ago

Might I add I think there may have been some confusion with:

And thats my fault because originally, before we had this cool nginx thing which routes to places for us, I had to make sure there werent any "duplicate" routes between the vue-router and go-ssb-room's router. So i did a second route /profile/alias/{alias} instead

cooldracula commented 1 year ago

Ah, thank you for this clarity! I fully missed that alias segment.

I have an example of this working on my test server. Try going to https://zach.ansible.fun. It should redirect you to https://ansible.fun/profile/alias/zach and you'll see my ssb profile.

Is this the desired behaviour?

(note: planetary.pro/profile/alias/zach will still not load anything i think beceause my profile is set to private. It works on ansible.fun, because the test server ignores that opt-out toggle)

chereseeriepa commented 1 year ago

Yup that's exactly what it should be doing :) Nice work 🎉🥳

mplorentz commented 1 year ago

I think this is all functioning correctly. @cooldracula ready to close?

cooldracula commented 1 year ago

yep, i think it's good to close!