-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for external file stores #3
Comments
Your ideas are interesting @almereyda. I wonder if you could spell out how you'd imagine credentials or authentication would be handled for the grist-static case, I can't quite picture it. |
Most of these protocols align around OAuth2/OIDC primitives and implicit auth grants. It is well exemplified in StackEdit.io (benweet/stackedit), how such an integration can play out: The client libraries of said platforms are surfaced in one's own application, and bring their own login flows + data stores. 0data.app also names fission.codes, but I had never tried that. After the clients are authenticated against their individual data stores, one uses the provided sinks and taps for CRUD in the browser, and that's it. Eventually a dedicated "save" or "auto-save" feature might be needed, to synchronise between server and client, when no such protocol is provided already. With Solid it's even fun to access other people's "pods" and their content via CORS, either publicly or with WebACL. S3 odds out of the listing, as it requires the creation of signed (capability) URLs for third party users, either manually or by another dedicated web service. A nice user platform on S3 is Notea, but that's not client-side application, very much like grist-core then. But I'm sure it could be done client-side, given a separate auxilary service to exchange signing tokens for authenticated sessions some place else. |
@almereyda if you were to support one first external file store for grist-static, what would it be? I looked at StackEdit.io but did not find a clear model to follow, maybe I missed it. |
Since this is all client side, credentials and authentication to files is debatably pointless. The files should be public. |
The upcoming export and import logic could also be hooked to the client libraries of:
I had expressed similar ideas in gristlabs/grist-core#359 (comment) before, but leaving it here, since the last newsletter asks for feedback.
This would make Grist Static a collaborative web application.
The text was updated successfully, but these errors were encountered: