Decide on interface for whitelist support about holo-auth HOT 20 CLOSED

It is possible to get all contacts in one shot from freshdesk API: /api/v2/contacts?company_id=our_company_id, where our_company_id is a certain int that was assigned to those with access to forum. Are we even still using freshdesk forum??

What needs to be checked is how whitelisting is correlated to signing up to freshdesk and how to keep it permanently synced. @yegortimoshenko @marycamacho

from holo-auth.

The whitelist is a subset of the Freshdesk sign ups.

from holo-auth.

@peeech

It is possible to get all contacts in one shot from freshdesk API: /api/v2/contacts?company_id=our_company_id, where our_company_id is a certain int that was assigned to those with access to forum. Are we even still using freshdesk forum??

This probably belongs more to #4.

What needs to be checked is how whitelisting is correlated to signing up to freshdesk and how to keep it permanently synced.

This is jumping to a specific solution. We might not want to use Freshdesk at all for whitelisting, because syncing data is error-prone, requires polling, and incurs additional ops overhead (= us ensuring that sync service reliably runs). Instead, as suggested in OP, we might just import once and edit KV store directly, or offer a UI to edit KV store directly. TBH, I'd prefer if we don't sync up, unless we really want to keep using Freshdesk for this for other reasons.

from holo-auth.

And, as mentioned in #5 (comment), another possible solution is syncing data from Freshdesk over to KV store. This is hacky because of listed disadvantages. We will probably only be able to do it on schedule. If we end up going this route, #4 will serve as foundation for implementing syncing service.

from holo-auth.

I've sent this link to @marycamacho and invited her to provide her feedback and ask questions directly.

Here's what Mary's more recent message to me was:

We are open to the KV option if we get a CS login and we have explicit instructions and we especially need to understand risk.

@marycamacho Can you elaborate on examples of risks you might be concerned about?

from holo-auth.

This seems simple enough. I completely get that a single source of truth not in Freshdesk is important if the API is unreliable. And what you show here seems fine. Risk for me was akin to... 'how easy would it be for a user to accidentally deleted multiple records?' or 'can a user inadvertently (or intentionally) edit other data unrelated to the whitelist when logged in?'

from holo-auth.

Can I ask a few tangential questions or is later a better time for that? These questions would relate to the need (or lack thereof) for a host whitelist, the ability to change email/pw on host registrations for future testing, and when we might change the validation limiting more than one HP per email. None of this is urgent.

from holo-auth.

Can I ask a few tangential questions or is later a better time for that?

Sure! Now is great time.

from holo-auth.

Risk for me was akin to... 'how easy would it be for a user to accidentally deleted multiple records?' or 'can a user inadvertently (or intentionally) edit other data unrelated to the whitelist when logged in?'

Ok based on this @yegortimoshenko I think the following are the key questions on risk:

1. Can we limit the view and edit permissions on a CS account to this KV store only?
2. How easy would it be to reverse changes (whether accidental or malicious)?
3. Can we limit the CS account to only modifying the contents of the KV store? E.g. they can’t delete the store itself, only make it empty.
4. Am I right in thinking that a big mistake such as clearing the entire store would only impact future registrations, not users who are already completed the holo-auth process?

from holo-auth.

Can we limit the view and edit permissions on a CS account to this KV store only?

Yes.

How easy would it be to reverse changes (whether accidental or malicious)?

We can make daily backups if we go with direct Cloudflare KV UI access, and we can make audit log with ability to see and reverse any specific change and who did it if we go custom dashboard route (we can eventually upgrade to the latter when we have more time).

Can we limit the CS account to only modifying the contents of the KV store? E.g. they can’t delete the store itself, only make it empty.

Yes.

Am I right in thinking that a big mistake such as clearing the entire store would only impact future registrations, not users who are already completed the holo-auth process?

Yes.

from holo-auth.

@marycamacho Hope those responses answers your immediate questions on risk.

from holo-auth.

Cloudflare UI doesn't make it easy to delete or add more than one entry at a time, too.

from holo-auth.

Closing as resolved based on #10 (comment). @marycamacho I think it still would be great to discuss all of these tangential questions.

from holo-auth.

@yegortimoshenko Assuming daily backups have been set up, how do we get Mary a Cloudflare account with write access to this KV store and no read/write access to any other KV store?

from holo-auth.

@yegortimoshenko Bump re: getting Mary a Cloudflare account. Who's the right person to ask?

from holo-auth.

That would be @evangineer. I think, access can be limited to that single KV store (ID 5181f479e6d84fc9835c5195b08a7029).

from holo-auth.

Thanks

from holo-auth.

Mary's input on the poor browser-based UX for deleting entries is that deleting emails from the whitelist (even for changing) is rare vs. adding. She would rather deprecate Freshdesk ASAP so is happy to go along with the Cloudflare interface for now.

from holo-auth.

Cloudflare access to Workers resources including KV stores granted.

Details can be found here:
https://trello.com/c/nDlGlwl6

from holo-auth.

Thanks Mamading!

from holo-auth.