API-only access, per issue #150#222
Conversation
There was a problem hiding this comment.
This part shouldn't be necessary, cause it should reject the user on the socket.io connection try. I think we shouldn't have 2 positions in the code where we check permissions. Everything else looks fine. Will have a close look later
There was a problem hiding this comment.
Missed that. I'll remove the redundant checks.
|
The permissions checks I've added in SecurityManager.checkAccess appear to make an existing bug more prominent. When checking to see if a pad exists (because of the editOnly flag), a padID of "test 1" is passed to padManager.doesPadExists as "test%201". This results in the user being refused access to the timeline. This bug does not present when it's a group pad, however. I think there are several open issues related to this (#135, #215 and #136). Just thought I'd point out that this feature will make the bug more prominent. |
|
@jhollinger are you sure the space bug isn't fixed already? This should have fixed it Pita/etherpad-lite@5ea8dd6 |
There was a problem hiding this comment.
editOnly is by default true? why?
There was a problem hiding this comment.
Must have accidentally copied that from my settings.json file. I have corrected it.
|
Why did you decide to do 2 options? What would be the usecase where you would enable one but not the other? |
|
I thought it could be useful to require authentication (session). But once Limiting the pads which can be created (signed in or not) is quite another I'm open to combining them, if you think that's clearer.
|
|
@Pita Yes, the spacing issue seems fixed now. I had simply not pulled that change into my branch yet. |
|
Option "editOnly" makes it possible to control the creation of new pads. External application can use API for creation. But users can then use the pads both "embedded" or stand-alone and can invite other users, who might not be users of the external application, to contribute to the pad. Option "requireSession" limits the whole access to pads to the users of an external application. Both use cases seem useful and make sense to me, as they address different scenarios. |
|
merged, thx |
Pure primaries like #ff0000 cannot clear WCAG AA (4.5:1) against either ether#222 or #fff — the best either can do is ~4.0:1. No text-colour choice alone fixes that; bg clamping would be a separate concern. The test should therefore verify the *real* invariant: the chosen text colour must produce the higher contrast of the two options, regardless of whether that contrast clears any absolute threshold. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
First cut of textColorFromBackgroundColor computed contrast against pure black (L=0) and pure white (L=1), then returned the concrete ether#222/#fff the pad actually renders with. For some mid-saturation backgrounds the two comparisons disagreed — e.g. #ff0000: vs pure black = 5.25 → pick black → render ether#222 → actual 3.98 vs pure white = 4.00 → would-render #fff → actual 4.00 The helper picked the wrong option because it compared against the wrong target. Compare against the actual rendered colours so the returned text colour is genuinely the higher-contrast choice. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
First cut of textColorFromBackgroundColor computed contrast against pure black (L=0) and pure white (L=1), then returned the concrete ether#222/#fff the pad actually renders with. For some mid-saturation backgrounds the two comparisons disagreed — e.g. #ff0000: vs pure black = 5.25 → pick black → render ether#222 → actual 3.98 vs pure white = 4.00 → would-render #fff → actual 4.00 The helper picked the wrong option because it compared against the wrong target. Compare against the actual rendered colours so the returned text colour is genuinely the higher-contrast choice. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 participants
This implements an api-only mode, per issue #150. Actually it splits the issue into two settings which may be used independently or in concert:
requireSession: requires users to have a session (disables non-group pads)
editOnly: users may only edit existing pads - new pads can only be created via the api