feat: publish spaces and let anonymous users access to pages in published spaces
See demo: https://doc.hoie.kim/share/s/public/p/product-specification-T76LEgs2eq
This might resolve feature request #203 and #23
Note that there's a subtle difference: some requested a feature to publish pages while others wanted a feature to publish the whole spaces. This PR adds feature to publish spaces and all pages in published spaces will be accessible by anonymous users.
~~User interface changes:~~
- ~~
Publish spacebutton will be added next toAdd space membersbutton inSpace settings->Membersmodal.~~ - ~~Anonymous users won't have user icon and dropdown menu on the upper right hand corner~~
- ~~Anonymous users won't have space list dropdown or space setting menu in the side bar~~
- ~~Anonymous users won't have user preference update buttons in the page kebab menu~~
~~Authentication mechanism changes:~~
- ~~
JwtAuthGuardwon't throw exception if the "referer" header in the request implies that the request is from a published space. Due to this change I added anonymous user handling mechanisms for a few controllers~~ - ~~When the request is from a published space,
AuthUserdecorator will return anonymous user object. This object represents a hypothetical user data that is actually not stored in DB. This user object is useful when resolvingworkspaceAbilityandspaceAbility.~~
Updates on March 17, 2025
User interface changes:
Publish spacebutton will be added next toAdd space membersbutton inSpace settings->Membersmodal.- Published spaces have "Copy shared link" button in page header menu and page tree menu.
- Shared pages and spaces are accessible via URL starts with
/share, such as/share/s/myspace/p/mypage, etc.
Both backend and frontend endpoints for shared space are separated from the existing ones and have separate authorization process. To do this I created ShareController that has similar methods with SpaceController and PageController but does not have JwtAuthGuard. Instead it authorizes requests from unidentified users if the space in question is a "published" space.
@Philipinho I'll appreciate your feedback on this
Hi @hoiekim, I have had a look at your work. I would say, it looks mostly good, but I do not wish to open the core dashboard in this manner, as it would open us to potential security issues. It will be very difficult to manage permissions consistently.
I am considering the possibilities of public sharing, and I lean towards it having it's own namespace.
We can expose sharing through a set of routes, e.g mywiki.com/share/xzy. This way, we don't have to worry about trying to manage who has what access to what in both the UI and the Server.
Makes sense to me. I'll update as I get some time to work on it
@hoiekim @Philipinho - from a pure user perspective, I love the approach you've taken here - allocating a space to be published is definitely a good move in my opinion. Publishing at page level is very awkward to manage and leaves the potential for pages to still be public that you've forgotten about. Thanks for your hard work both!
@Philipinho Just pushed a new commit to apply your feedback. Let me know if it looks okay to you 😊
Despite its not even merged into master, I'm testing this in a production environment and I'm amazed with the feature so far. ✅ So far my tests are passing
Noticed that the compile fails after merging with the latest changes so rebased on main branch and resolved the error. All looks good now.
It would be great if single pages could be shared (not the whole workspace). I thought that the last patch added this.
@hoiekim
I've found a weird bug: Sometimes, not sure why, it shows the info for a second and then redirects automatically For example with this first link it redirects: https://test.wp.voz.cat/share/s/ideas/p/testing-workflow-ideas-U9UoGrVDLP But with these two others, it doesnt: https://test.wp.voz.cat/share/s/ideas/p/unofficial-mentorship-program-ePhW1o3sum https://test.wp.voz.cat/share/s/ideas/p/about-meetings-protocol-Xl7h0JnhDf Both for the same Workspace and I can't see a difference? (maybe it only affects the first doc in the list?)
@SirLouen Thanks for your efforts with testing. I experienced the same when I clicked the links you provided.
I think it's related with the linked pages inside the document. I suspect that the auth-required API endpoint is called while resolving the link. I'll fix this some time soon.
Regarding the feature to publish single page, I think we can leave that as a separate feature and can be added after this PR is merged.
Fixed the bug that certain extension elements in the editor caused re-direction to login page. I created another extension set called readonlyEditorExtensions, which has shared version of embedded elements like mention view, image, draw.io, excalidraw and etc.
@hoiekim I really appreciate the time and effort you’ve put into this. While the outcome looks desirable, there are too many code changes I do not agree with, which would make maintenance a burden. For example, the duplication of code in recent changes and the number of files impacted. Tbh, I don't think It would make it to the codebase in it's current form.
I am sorry that I am not able to give much feedback on this. I also want to be transparent that I am not yet ready to commit to the implementation of this feature. When I decide to, I am sure there would be much to learn from your implementation.
I hope this does not come off as rude or discouraging in contributing in other ways.
Honestly I'm disappointed but I'll take your words. Hope you'll find a better way around on this
@hoiekim this is not an optional feature for a system of this nature. I will be probably be forking for now your advances in this regard. Prob a ton of people will be appreciating all the polishes around this feature that you have been doing.
If I were @Philipinho I would have added this permanently into the trunk version until I had the time to code review it and back port it into an stable release. Probably he could take big parts, maybe not all, of the code for this purpose.
Also @Philipinho if you have a guy that is PRing you, why you don't give some tips on which direction from your point of view would be preferred to facilitate the integration this? Also if you check in issues this is not any close the number one requested feature by everyone. You have the helpers, the demand, you have everything in your hands, it's strange you are not taking the opportunity to make a massive step in the software by focusing in such minor feature.
Public page sharing is being worked on. PR: https://github.com/docmost/docmost/pull/1012. Closing.
PS: @hoiekim, I truly appreciate the time and effort you put in this PR. Thank you.