prepwork for FlowCrypt Enterprise Server integration

[tomholub]

Today, stack traces are sent to FlowCrypt API - done in Cather.report and Catcher.handleErr. There should be a way to send them to a configured FES instance.

[tomholub]

The extension will have to have a way to figure out which endpoint to send report to when an error actually happens.

Ways to address this:

1. check local storage for OrgRules when the error happens, then use that url (pointing at EKM)
2. check customer.com/.well-known/flowcrypt/config for config that would have the API in it (pointing at EKM)
3. during initial page rendering, store the url as a (global?) variable. Retrieve it when handling errors (would possibly not work in content scripts and background page, which would need a separate way to set the variable). If it has the url, send there (pointing at EKM)
4. opportunistically report it to a place like customer.com/.well-known/flowcrypt/errors. If anything is there to listen and returns err 200, consider it done. If err 404, then send to flowcrypt.com/api

The problem with EKM is, it may be run and accessible only within network. So there will have to be something in the DMZ to handle this anyway, so we have to use either https://github.com/FlowCrypt/enterprise-admin-panel directly (which will server OrgRules anyway?), or yet another EKM service for log collection that forwards the requests and is in DMZ (similar to WKD Server).

[tomholub]

Since customer.com/.well-known/flowcrypt/config needs to be in the DMZ anyway, and OrgRules need to be served from DMZ anyway, then we might as well also have a service running there (or all three of them together) that collects exception logs.

Therefore this would all be implemented in the EAP linked above, and possibly never touch the EKM.

[tomholub]

@seisvelas @wiktor-k please let me know if you have any thoughts or feedback after reading the above. I'm not sure if it provides enough context, which I can provide based on your questions.

[wiktor-k]

Sounds like something that should be stored per-account. So if someone has e-mails john@gmail.com and ceo@corp.com then the gmail.com (maybe?) should go to our normal endpoint and corp.com ones to them.

In general I think it would be good to read the config once at startup and don't check on every single error (due to performance reasons). OTOH persisting the endpoint in localStorage could be too drastic in case customer changes their endpoint.

(Btw standard way to put endpoints is to use RFC 6415 .well-known/host-meta.json file where you just invent your own rel (like https://flowcrypt.com/endpoints/errors) that serves as a key to lookup. Example here)

[tomholub]

Sounds like something that should be stored per-account. So if someone has e-mails john@gmail.com and ceo@corp.com then the gmail.com (maybe?) should go to our normal endpoint and corp.com ones to them.

Definitely. After all, since settings are domain based, to know the domain we need to know the email account, so therefore each email account may have different mechanism.

Which leaves a question of what to do with errors before user logs in. These would probably still go to our backend, if customer agrees. Alternative would be to block them by default, for everyone.

(Btw standard way to put endpoints is to use RFC 6415 .well-known/host-meta.json file where you just invent your own rel (like https://flowcrypt.com/endpoints/errors) that serves as a key to lookup. Example here)

Excellent. So it would look something like this? https://customer.com/.well-known/host-meta.json

{
  "properties": {},
  "links": [
    {
	  "rel": "flowcrypt:enterprise-dmz-api",
	  "href": "https://flowcrypt.customer.com/dmz/"
    }
  ]
}

And then the extension would know to call eg https://flowcrypt.customer.com/dmz/error or https://flowcrypt.customer.com/dmz/org-rules to get whatever it wants?

One advantage of having a custom well known link (.well-known/flowcrypt) is that we can provide them tools that will generate and host it, so it's less work for them. If they have to incorporate it into their existing well known file, or in the future need this for some other solution, it may get complicated for them.

But generally better to follow standards.

[tomholub]

Ping on the above whenever you are less busy, in particular, does this look ok?

https://customer.com/.well-known/host-meta.json

{
  "properties": {},
  "links": [
    {
	  "rel": "flowcrypt:enterprise-dmz-api",
	  "href": "https://flowcrypt.customer.com/dmz/"
    }
  ]
}

Or should the rel be an actual URL?

[wiktor-k]

Hi, nope it doesn't need to be a URL it needs to be a URI (URLs are just a subset of URIs). The example you posted is OK although I'm not sure if it improves upon something URL-like https://flowcrypt.com/enterprise-dmz-api (URL has added benefit that you can host docs on that URL in the future but it's not critically important).

[tomholub]

Ok, the URL is interesting wrt hosting information on it, especially if this is the convention 👍