This is a feature I would love to have: leaving some directories open (without a password) and other directories password protected.
+1 big time! Here’s my use cases and ideal implementation
Use cases
Public posts - I want some pages completely public, even if they link to private pages.
Drafts for friends - I want to send friends posts to give feedback on before I’m ready to share them more broadly.
Private subject areas - I want to have private, password-protected sets of pages for certain groups of readers, such as my family or a project group.
Implementation ideas
Share page - Generates a link to share an individual page with someone, like Craft’s Share to Web example above.
Multiple access groups - Pick which named password groups have access to which pages, using a list of items in the publish: property (e.g. publish: projectX, drafts, family, substacksubs). Password groups autocomplete in the publish property when typing.
Visibility defaults - Pick whether site is default public vs private. Default public allows all notes are public except for ones with a password group (e.g. everything but publish: family or whatever group), and default private would be visa versa (nothing but publish: public). This is similar to how we use publish: false today.
Link password prompts - When clicking on a link that goes to a private page, I’d love to see this pop up a password prompt.
Login page/prompt - Offer a login button or page where a password could be entered. This would then allow Publish to have a ‘hide inaccessible links’ option, which wouldn’t render links to pages that the user didn’t have permission to access. This login page would be the first step toward future user accounts, which could be implemented atop the password groups concept (user X has access to groups A and C).
Password group management - Currently to change a publish site to on vs off you have to delete all the passwords. That’s a bit clunky and unintuitive. If the above were implemented, I think it’d be better UX to also allow disabling passwords using a radio button for each password group . And if you chose to delete a password, you’d be asked if you wanted to have a batch removal of that password group from all the pages where it appears in the publish property.
There’s other possibilities to improve UX like setting password groups based on folder contents, but since everything in obsidian is file-based that’s probably a bit beyond the scope.
Right now my workaround to have both some notes public and the rest private would be to publish on two separate sites (mysite.com and notes.mysite.com) with the former being a vault-within-vault since its a subset. However this would break links, is complex, and may have unforeseen issues & data loss so I’m hesitant to do it.
4 Likes
+1 - sorely needed
+1
plenty of use cases for selective pages with password protection without collaboration.
Could also be solved with a YAML property password: XYZ. When present, opening the note triggers the demand for inputing the designed YAML key before displaying the full note.
Just another +1 for this idea. I’d love to have a members-only section to give to people. It would be even better if you had to grant people access via an account (for those of us looking to sell courses and things).
2 Likes
+1, this would be very useful!
Question to the community — if not through Obsidian Publish, would it be possible to password protect specific pages/directories using Cloudflare Access as long as you’re hosting your Obsidian Publish site on a custom domain? It seems this might work but I have to research it more. Here’s more info on Cloudflare Access:
+1 this is essential for the way I use and would like to use obsidian publish!
+10 for this!
+100
I joined just to upvote on this. Sorely needed!
1 Like
- That would be a nice feature.
Been desiring this for ages!
+9001
很实用的功能，也很需要
As this is an English speaking forum, please post in English or include an English translation in the future. Thanks.
YES, PLEASE! I need this for a few things.
+1 I use Publish for our company’s knowledge database and need to be able to grant access to different users depending on their role (sales, editorial, marketing). This feature would open Publish up to a huge amount of use cases it simply can’t support right now.