Feature/support subdomains

[henriquecbuss]

What issue does this PR close

Addresses #495, closes #470

Changes Proposed ( a list of new changes introduced by this PR)

• Load appropriate community based on URL
• Store all community data only on LoggedIn
• Remove symbols (like 0,CMB) from URLs
• Add new community configuration pages
  • General information (name, description, subdomain, etc)
  • Currency (inviter reward, invited reward, minimum balance)
  • Refactor old edit page so it can only create new communities, and not edit existing ones
• Auto redirect the user when changing communities
• Share local storage with all domains
• Improve loading gif
• Change what happens when the user accesses the application:
  • Logged in:
    • User is member of the community: behave as usual
    • User is not a member of the community, and community doesn't have autoinvites: show community selector (closes Add community selector as a "welcome message" #482)
    • User is not a member of the community, and community has autoinvites: show "Join community" page and let them sign in
  • Guest:
    • Community allows for autoinvites: show "Join community" page and let them sign in
    • Community doesn't allow for autoinvites: redirect to https://www.cambiatus.com/

How to test ( a list of instructions on how to test this PR)

• Try accessing different communities by prepending the name of the community to the url (e.g. muda.localhost:3000) and seeing if the correct community is loaded. Try this with communities that:
  • You are a member of (should load the community fine)
  • You are not a member of and has auto invite (should invite you to join the community)
  • You are not a member of and doesn't have auto invite (should show the community selector)
• Try changing something (e.g. language) in one community, change to another community and see if the changes persist
• Try changing the community via the community selector, and see if you're redirected to the correct url
• Try creating a new community (via /community/new), and see if it behaves as expected
• Try changing the settings for your community and see if everything behaves as expected
• Without being logged in, try to access communities that have and don't have autoinvites - they should show the "Join community" page, and allow you to sign in if they allow for autoinvites
• Being logged in, try to access a community you're not a member of yet, but that allows for autoinvites - should show the "Join community" page, with the community information, and let you sign in to the community

[henriquecbuss]

Ok @lucca65 apparently your community (I'm assuming it's happening with 0,MIZU) is set as expiry instead of mcc, but it doesn't have an entry in the expiryopts table, so it obviously errors out when trying to get data from that table. Maybe this was some configuration problem when you created the community? 🤔

[henriquecbuss]

When clicking on a notification of a different community I'm in, it asks for my 12 words after the redirect. I've opened a fresh session, logged in to MIZU and tried to go to a transfer for CMB, after the second login, i could go back and forth without having to provide the 12 words again. This happens at every different community I try

Damn, I really can't replicate this 😬. The way the app starts up right now is:

1. Check if the url ends with /globalstorage. If so, execute the app as globalstorage. If not, keep going.
2. Check if that specific domain has synced with globalstorage at least once (this is done via a localStorage flag that's stored only on the subdomain, not on globalStorage).
   2.1. If the domain hasn't been synced and there is user information on the domain's localStorage, send all relevant keys to globalStorage and overwrite anything there
   2.2. If the domain has been synced, or there isn't any user information on the domain's localStorage, get all relevant keys from globalStorage
3. Set the flag that determines if the domain has been synced with globalStorage as true
4. Run the app as usual, but using globalStorage instead of localStorage

(By user information I mean the USER_KEY)
I can't really think of other edge cases that you might be falling into... These steps all happen before we even start the Elm app.

Can you check on the console if there is some logging that says you've been logged out? (It would probably be shown as logout port started or something like that). You can also check the storage tab on the developer console and check what's being stored in the domain's localStorage and what's being stored in the staging.cambiatus.io domain

[heltonlr]

@heltonlr if you manually go to the website you entered, does it work? I think you're probably using an invalid website

Ok, I tried using a valid url now. Works well

[lucca65]

Ok @lucca65 apparently your community (I'm assuming it's happening with 0,MIZU) is set as expiry instead of mcc, but it doesn't have an entry in the expiryopts table, so it obviously errors out when trying to get data from that table. Maybe this was some configuration problem when you created the community? 🤔

oh. sorry then bro, my bad, I should have checked it before hand. it won't happen again 💪

[lucca65]

I must suppose then its something on Safari. I've tested it on Safari, Chrome and Firefox and it only happens on Safari consistently. Which is a problem because we must support Apple ecosystem, as it is almost 20% of our user base. We have a few alternatives:

1. VM your way into a windows and install safari
2. get an iPod touch / iPhone and test it calling it to your machine
3. try Browserstack

Either way we need to support it bro ):

[lucca65]

🍬

[henriquecbuss]

@lucca65 Bad news on the safari support... After a lot of testing and digging, I stumbled upon this StackOverflow thread, which is pretty much exactly what we're trying to do. Safari introduced a security feature where we can't do this (with localStorage), as far as I understand. I've tried using globalstorage.staging.cambiatus.io/globalstorage (so it's considered first-party), and it also didn't work.

The option introduced in the Storage Access API is to use cookies instead of localStorage, which I really don't like, but it seems to be our only option to support the latest safari releases 😬. What do you think we should do?

[lucca65]

damn... really? 😢

[lucca65]

This is so bad, I needed a time to digest this. "Aos 45 do segundo tempo" 😩

Its bad that advertisers used this feature to fuck privacy up. Damn Well, we have no choice and we should be more attentive about Apple's ecosystem. Safari is the new Internet Explorer

[henriquecbuss]

Should we try using cookies then?

[lucca65]

we have no other alternative, right?

[henriquecbuss]

I don't think so 😩

[lucca65]

yeah, I'll let the team know this is going to take longer yet ):

[henriquecbuss]

@lucca65 everything should work now! We're using cookies, and moving all the localStorage data people might have to cookies as well, so they're not logged out as soon as the update is released.

Also, if we want to keep sessions between communities when developing on localhost, we should use urls like cambiatus.staging.localhost:3000, because domain names must have at least 2 dots, but we should automatically be redirected to that url when trying to go to localhost:3000 anyway, so it's no big deal!