-
Notifications
You must be signed in to change notification settings - Fork 537
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
Enforced read-only mode for some viewers #1
Comments
Thanks for creating issue #1 (and hopefully there'll be more to come)! So would it be ok if, say, http://ethercalc.org/pagename becomes read only (with a server setting), but http://ethercalc.org/pagename/edit is password protected, for all values of "pagename"? A full-fledged ACL-to-Page mapping is possible too, of course, but I'm trying to avoid over-complicating the administrative interface. :-) |
Yes such a 'setting' would totally satisfy our needs, as we have total control of the server which is running ethercalc. As for more issues - yes I will create some ;-) |
I don't want to sound impatient - but just need some info for planning: Thanks! :) |
Sure! I should've communicated my plans better. :-) There's definitely intention to implement this. There's a OSDC.tw hackathon tomorrow where I'll be hacking (and hopefully teaching other folks) on EtherCalc to improve its REST API and read-only support with "ethercalc --key SECRET", so it should happen this weekend if not sooner. |
To enable this mode, start ethercalc with a "--key" parameter: ./bin/ethercalc --key 85b5dd7a-8afe-11e1-bca8-002332d309a4 Under this mode, /:room simply redirects to the /:room/view URL. Using a reverse proxy to authenticate or restrict access to the /:room/edit URL scheme is currently required.
Hi @comm2k, please pull the latest code (900d279) and see if it is approximately what you'd like? To quote the commit message:
If you'd like Basic Auth or some other way to restrict access to /:room/edit (instead of using a reverse proxy), please open a new issue for that. Thanks for the suggestion! :-) |
Also: Instead of setting up reverse proxy, if you're embedding EtherCalc within another app, it's also possible to manually construct an authenticated-edit link for selected users. See the hmac function in main.coffee:
Here KEY is the value passed to "ethercalc --key", and ROOM is the spreadsheet page you're editing. After calculating the digest, passing it to /ROOM?auth=DIGEST will show an editable rendering of the page. Under that use case, simply comment out the three lines in
will make it impossible for users to gain edit access without getting the auth token from a service that knows the shared-secret KEY. Let me know if this helps. :-) |
To enable this mode, start ethercalc with a "--key" parameter: ./bin/ethercalc --key 85b5dd7a-8afe-11e1-bca8-002332d309a4 Under this mode, /:room simply redirects to the /:room/view URL. Using a reverse proxy to authenticate or restrict access to the /:room/edit URL scheme is currently required.
Can this be put into the documentation? There should it go, instead of referring from the documentation to an issue ... |
We'd like to use ethercalc to provide real-time updates to people in different locations.
Scenario:
The original data (simple time-schedules) is copied from Excel and pasted into an ethercalc spreadsheet manually - everytime a change is made. However for certain 'viewers' in ethercalc we'd like to prevent them from being able to edit/manipulate the spreadsheet.
In other words a very simple user/group or access rights system would enable us to allow some people ('planning team') to enter updates, whereas others (clients) just receive the updates via ethercalc.
Thanks :-)
The text was updated successfully, but these errors were encountered: