ogn.app domain conflicts

[mikeshultz]

Having some issues with domain conflicts. Adding the recent DNS and shop_domains conflict check exposed a bunch of issues we have with how domains are used and assigned.

Here's an example of a shop in a stuck state right now (names censored):

dshop=> select id, name, hostname, auth_token from shops where hostname = 'example';
  id   |      name       | hostname |   auth_token    
-------+-----------------+----------+-----------------
 10010 | Example Shop    | example  | example-shop
(1 row)

dshop=> select id, shop_id, domain from shop_domains where shop_id = 10010;
  id  | shop_id |         domain          
------+---------+-------------------------
 4120 |   10010 | example-shop.ogn.app
(1 row)

A recent bugfix #967 exposed an issue this bug created where shops were initially created on one ogn.app hostname, then on subsequent deployments moved to another one without removing the old records. So now on their next deployment, it attempts to move them back to the previous name. In the example, we have these zombie records that aren't actually assigned to a shop:

$ dig example.ogn.app

; <<>> DiG 9.16.12 <<>> example.ogn.app
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51428
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 52a7a3cda6df74b6561beea7609ed7cac51e07fb77874b81 (good)
;; QUESTION SECTION:
;example.ogn.app.            IN  A

;; ANSWER SECTION:
example.ogn.app.     60  IN  CNAME   dshop.originprotocol.com.
dshop.originprotocol.com. 300   IN  A   35.230.64.141

;; Query time: 580 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri May 14 14:04:26 MDT 2021
;; MSG SIZE  rcvd: 125

It does actually serve a shop right now for some reason which might be another bug, so not sure how that's working without a shop_domains or accurate shops.hostname value.

shops.hostname is enforced UNIQUE, so we can probably rely on that. However, with these zombie records, we can't know for sure if these are dshop-usable, or used for some other random system or project. Not sure there's a way for dshop to know it " "owns" a subdomain and update it if it isn't in the DB. Might be worth looking into cleaning up the zombie DNS records.

Shy of putting these shops on their own reserved namespace (e.g. example.shop.ogn.app), I'm not sure what to do here other than fail on these shops. And a migration like that sounds... challenging. Just allowing records to be overwritten blindly opens up a potential security hole on anything else on this DNS zone.

Right now I think some existing shops are unable to deploy, though it's unclear how prevalent this is.

CC @nick @franckc

[franckc]

Knowing how many shops are impacted would help greatly determine the priority... Would a query similar to this help us getting that data?

select count(*)
from shop_domains, domains
where shops.id=shop_domain.shop_id and domains.domain = concat(shops.auth_token, '.ogn.app')

[mikeshultz]

Don't think that would be accurate. Lots of shops may have matching hostname and auth_token and not be in an error state.

Thinking the only way to really check for a shop in this state would be to look for shops with the hostname and auth tokens being different, see if DNS is configured for both auth_token and hostname, and that no other shop is configured to use that hostname. Kind of a tricky PITA.

[cleancoindev]

https://seven-mountain.ogn.app - this shop is stuck looping at the Publishing.... I can change some of the things such as products but i cannot change the theme.

[phyninja]

@franckc @mikeshultz, On DShop's support channel on Discord, there are currently reports from 3 (additional..?) users who seem to have been impacted.

Update: July 2, 2021

Another shop admin reported being affected by this issue. Shop domain: guaro-store.ogn.app

[phyninja]

Hi,

My understanding is that starting today, (most) shop admins will have migrated their shops away from the ogn.app domain. If true, will there be a need to make changes to the codebase to respond to this issue?

[SocialgeeksAus]

Hi team, this issue seems to be blocking successful deployments of DShop on other domains. Is there any way we can get a GitCoin bounty up to fix this?