Details
Load the web app when logged in and when logged out. Check that the app works and there are no errors in the console.
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
web/redux/default-state.js | ||
---|---|---|
84 ↗ | (On Diff #30963) | What about squadcal.org? |
web/redux/default-state.js | ||
---|---|---|
84 ↗ | (On Diff #30963) | It's an interesting question. Today we use squadcal.org as the default on native. One advantage of this is that it avoids any using web.comm.app for both serving the web app and for my keyserver. Using squadcal.org here would make it easier to say "web.comm.app just serves the web app", which is perhaps a follow-up task to the "separate web and landing from keyserver" goal. However, I could imagine there might be CORS issues or something if a page loaded from web.comm.app is sending requests to squadcal.org. |
web/redux/default-state.js | ||
---|---|---|
82–84 | This is a significant regression that makes it impossible to run a staging environment for the keyserver for testing purposes. It appears that your changes make it impossible to host the Comm web app on any domains other than web.comm.app |
web/redux/default-state.js | ||
---|---|---|
82–84 | Then again, not clear how this should work in a multi-keyserver world, where keyserver and web are separated... |
web/redux/default-state.js | ||
---|---|---|
82–84 |
Are we doing something like this currently, or do you mean the general staging environment that we had been working towards? But if it's not immediately needed, than this should get handled automatically in a multi-keyserver world if I understand everything correctly. There will be some discovery service that keyservers can register with, and from which clients can get information about available keyservers and connect to them (ENG-4135). |
web/redux/default-state.js | ||
---|---|---|
82–84 |
Yes, sometimes I need to test things in a publicly-addressable way, so I've set up a mirror of Comm (with an empty database) at comm.domains. So far I've only had two cases where I've needed this: primarily testing SIWE, but also recently I wanted it for testing master against an old version of Safari via an online tool.
We've talked about this, but heads-up that in terms of sequencing, I'm thinking of that one as a sort of a "follow-up" to the multi-keyserver launch... we could launch with the expectation that users input keyserver URLs manually.
I think this would be a good idea, but we should use getCommConfig for it. In the cases I've listed above, I actually didn't need a staging keyserver, just a staging web app / landing page. It would've worked fine if not for the CORS issues that prevented the staging web app from loading (it crashes trying to access the prod keyserver). |
We've talked about this, but heads-up that in terms of sequencing, I'm thinking of that one as a sort of a "follow-up" to the multi-keyserver launch... we could launch with the expectation that users input keyserver URLs manually.
Makes sense. This simpler version also works for the staging needs.
I think this would be a good idea, but we should use getCommConfig for it
I'm going to handle this regression as part of my remaining work for web separation. We can use the url facts to set the correct CORS and inject the urlPrefix as a variable into the html which the web app will use (so instead of having "dev" and "prod" setup it will be dynamic based on url facts).
This is a bit of a step-back because it again couples keyserver with web app, but we can easily remove it after it's not needed when we implement the keyserver selection (so user can just enter a keyserver URL).