It turns out that having an account on a PDS that shares the same root domain as an AppView is problematic, and not currently a good idea.

You'll likely only notice this if you're trying to access your AppView with an account hosted on the same domain name, e.g. having an account at @your-domain.social hosted on a https://pds.your-domain.social while trying to trying to access your AppView at https://your-domain.social.

I remember reading about this on Bluesky, when @stellz.club posted a few months ago:

stellz:web

@stellz.club

is there some issue with doing Oauth to a PDS that's on the same root domain as your app?
my pds is pds.stellz.club & my app is wallet-link.stellz.club, i get this error in the Oauth error screen when i try to login:

"Forbidden sec-fetch-site header 'same-site' (expected cross-site,none)"

6

Fortunately @matthieu.bsky.team posted the reasons for this feature, so we can understand a bit more about why this happens:

Matthieu 🦋

@matthieu.bsky.team

This is actually a "feature". Since PDS can host HTML Blobs (and thus JS), I wanted to prevent XSS attacks. I think we could reasonably make this configurable though, and allowlist some uris (checked against the referer)

1

Steps to migrate a PDS to a new domain

In order to resolve this issue, you'll need to migrate your PDS to a new root domain. Below are the steps to do this.

Modify your DNS records to point the new domain to the server.

Login to your DNS provider, and add an A record for the new domain, e.g. pds.new-domain.social pointing to the IP address of the server

This may take a few minutes for the DNS records to propagate.

As a note, I left the original A record pointing from the old domain e.g. pds.old-domain.social to the server.

Modify the Caddyfile to add the new domain.

My Caddyfile is at /pds/caddy/etc/caddy/Caddyfile.

{
	email info@new-domain.social
	on_demand_tls {
		ask http://127.0.0.1:3000/tls-check
	}
}

# Bluesky PDS - with on-demand TLS for user subdomains
*.pds.old-domain.social, old-domain.social, *.pds.new-domain.social, new-domain.social  {
	tls {
		on_demand
	}
	reverse_proxy http://127.0.0.1:3000
}

Modify the pds.env file to add the new domain.

My pds.env file is at /pds/pds.env.

PDS_HOSTNAME=new-domain.social

Restart the docker containers

Simply restarting the docker containers, or stopping and then starting the docker containers won't change the ENV values.

You'll need to stop and then use docker composer to start a new container to apply the new ENV values.

docker stop pds caddy
docker compose up -d

Try loading the PDS in the browser

Visit https://pds.new-domain.social to see if the everything is up and running.

Manually apply the PLC records to the new domain

@mary.my.id has a boat load of tools for AT Protocol. Shoutout to @iame.li for pointing me to this. I used the plc-applicator to apply the PLC records to the new domain.

• Go to the plc-applicator

• Enter the handle of the account you want to migrate to the new domain

• I used the rotation key I made when I moved the PDS from Bluesky to my domain using @baileytownsend.dev's PDS MOOver tool.

• Change the value of the "endpoint" field to the new domain, e.g. https://pds.new-domain.social

• Click next, enter the 3 confirmation codes, and click "Apply".

That should be it! Massive shoutout to @mmatt.net for providing all these steps in a more succinct post on Bluesky!