Deny access to posts with exception
37 views
Skip to first unread message
Konzertheld
May 11, 2013, 1:44:41 PM5/11/13
to habar...@googlegroups.com
Hello developers,
simple idea, no clue how to do it. I want to hide posts from everyone except if it is accessed via a secret key (the google way of sharing photo albums). So basically I want to check a checkbox on the publish page which will cause that post to be hidden from everywhere, only accessible via direct call with that secret (which is easily done with rewrite rules).
I can't use private posts for that because I can't allow access to private posts anywhere. So if I use it to deny access, access will always be denied.
I also can't use postinfo to store if that post is protected because there is no "not:info" for Posts::get(), so I can't filter Posts::get() results.
What should I use? Maybe it's possible to temporarily grant the anonymous user permission to that specific post? Someone somewhen said something about post-specific ACL. I've thought about fake-identifying as some user when a secret is used, but that will not work as long as I do not create one user per protected post (I won't do that).
So, if someone has an idea or knowledge about functionality, please let me know. :)
Konzertheld
Chris Meller
May 11, 2013, 3:27:44 PM5/11/13
to Habari Dev
Not to say this is the way it should be done, but Posts::get() supports:
* - has:info => a post info key or array of post info keys, which should be present
* - all:info => a post info key and value pair or array of post info key and value pairs, which should all be present and match
* - not:all:info => a post info key and value pair or array of post info key and value pairs, to exclude if all are present and match
* - any:info => a post info key and value pair or array of post info key and value pairs, any of which can match
* - not:any:info => a post info key and value pair or array of post info key and value pairs, to exclude if any are present and match
--
--
To post to this group, send email to habar...@googlegroups.com
To unsubscribe from this group, send email to habari-dev-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/habari-dev
---
You received this message because you are subscribed to the Google Groups "habari-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to habari-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Konzertheld
May 13, 2013, 3:56:06 PM5/13/13
to habar...@googlegroups.com
Thanks Chris, I overlooked those two. Unfortunately, I realized using postinfo was of no help anyway.
The Sharedraft plugin does indeed do exactly what I want. Thanks for the hint, Les. It is though not compatible with newer versions of Habari, because it does not take care of presets. So for future use, Passcode will propably do a better job, or Sharedraft needs modification.
Am Montag, 13. Mai 2013 00:56:39 UTC+2 schrieb Les Henderson:
Am Montag, 13. Mai 2013 00:56:39 UTC+2 schrieb Les Henderson:
I realize that Owen has created a new PassCode plugin and uploaded it to the Addon Catalog for your review but I am wondering why his one from last year, ShareDraft, wouldn't also do the trick.
https://github.com/habari-extras/sharedraft/blob/master/sharedraft.plugin.xml
Please forgive my ignorance as I try to grasp all the Oauth and permissions lingo.
Owen Winkler
May 13, 2013, 5:38:36 PM5/13/13
to habar...@googlegroups.com
On 5/13/2013 5:09 PM, Les Henderson wrote:
> Ha. Now I have to research even a basic understanding of presets.
>
> Luckily ShareDraft is by Arthus and Ringmaster, so an update isn't
> entirely out of the question.
Sharedraft was designed to allow you to share the draft of a post with
someone (say, have a friend edit it) prior to publication. As a result,
it generates a single hash on a single URL so that you can share that
URL with the intended person for review. I've hacked the plugin a few
times to get it to display non-draft posts regardless of permission, but
it still uses that generated hash. When the hash is out, there's no
calling it back. If someone gets the URL, the post remains available on
that hash until it is deleted. Also, the post is only visible via the
single post page, not within any post listings, because it does not
Sharedraft needs to be updated to work with 0.10 to account for new
FormUI, which uses different controls. I don't know what changes might
be required to account for presets, though I imagine that its
interaction might have something to do with it only affecting draft
posts by default.
Passcode works differently.
Passcode is unfinished, but its intended functionality is to allow a
visitor to specify one or more passcodes which will be cached with a
cookie or in the session, and then used as a substitute for user-based
authentication.
Passcode is designed to work with master. There were recent changes to
the query class that are required for Passcode to work. As a result,
Passcode requires 0.10.
Passcode creates a separate table for the purpose of storing passcodes
that grant entry to specific posts. Different passcodes can be stored
for any single post. The implication is that you can permit one
passcode access to posts 1, 2, and 3, and another passcode access to
posts 3, 4 and 5, allowing some overlap between the two. If a user
supplies both passcodes, then both sets of posts should be available.
Where Sharedraft tries to remove the restriction to show only published
posts when a hash is supplied, Passcode integrates with the parts of the
posts query that deal with the permission system directly. As a result,
if you've supplied a valid passcode, you should see qualifying posts
within any listing that would hold them. This is a significant
difference from Sharedraft, which cannot do this well with its current
architecture.
Perhaps more interestingly, Passcode serves as an adequate model for how
Habari's native permission system can be augmented to account for
external permissions.
Passcode yet needs user-facing UI elements, such that passcodes can be
set on individual posts and users can supply passcodes to reveal those
protected posts. These interface elements are reasonably trivial to add
given the new capabilities of the latest revisions to FormUI. Had I
done that rather than write this email, it would probably be done already.
Sharedraft is not a poor plugin. It can be tuned to get close to what
was originally requested, but it was not intended for that use, nor is
it the most efficient for that purpose. For the purpose it was designed
- sharing a draft post with a friend for review prior to publication -
it succeeds. While it's likely that the plugin will be updated for
0.10, it will likely not be updated to support features more than what
it already supplies.
Hopefully that explanation of the differences between these plugins is
helpful.
Owen
> Ha. Now I have to research even a basic understanding of presets.
>
> Luckily ShareDraft is by Arthus and Ringmaster, so an update isn't
> entirely out of the question.
Sharedraft was designed to allow you to share the draft of a post with
someone (say, have a friend edit it) prior to publication. As a result,
it generates a single hash on a single URL so that you can share that
URL with the intended person for review. I've hacked the plugin a few
times to get it to display non-draft posts regardless of permission, but
it still uses that generated hash. When the hash is out, there's no
calling it back. If someone gets the URL, the post remains available on
that hash until it is deleted. Also, the post is only visible via the
single post page, not within any post listings, because it does not
Sharedraft needs to be updated to work with 0.10 to account for new
FormUI, which uses different controls. I don't know what changes might
be required to account for presets, though I imagine that its
interaction might have something to do with it only affecting draft
posts by default.
Passcode works differently.
Passcode is unfinished, but its intended functionality is to allow a
visitor to specify one or more passcodes which will be cached with a
cookie or in the session, and then used as a substitute for user-based
authentication.
Passcode is designed to work with master. There were recent changes to
the query class that are required for Passcode to work. As a result,
Passcode requires 0.10.
Passcode creates a separate table for the purpose of storing passcodes
that grant entry to specific posts. Different passcodes can be stored
for any single post. The implication is that you can permit one
passcode access to posts 1, 2, and 3, and another passcode access to
posts 3, 4 and 5, allowing some overlap between the two. If a user
supplies both passcodes, then both sets of posts should be available.
Where Sharedraft tries to remove the restriction to show only published
posts when a hash is supplied, Passcode integrates with the parts of the
posts query that deal with the permission system directly. As a result,
if you've supplied a valid passcode, you should see qualifying posts
within any listing that would hold them. This is a significant
difference from Sharedraft, which cannot do this well with its current
architecture.
Perhaps more interestingly, Passcode serves as an adequate model for how
Habari's native permission system can be augmented to account for
external permissions.
Passcode yet needs user-facing UI elements, such that passcodes can be
set on individual posts and users can supply passcodes to reveal those
protected posts. These interface elements are reasonably trivial to add
given the new capabilities of the latest revisions to FormUI. Had I
done that rather than write this email, it would probably be done already.
Sharedraft is not a poor plugin. It can be tuned to get close to what
was originally requested, but it was not intended for that use, nor is
it the most efficient for that purpose. For the purpose it was designed
- sharing a draft post with a friend for review prior to publication -
it succeeds. While it's likely that the plugin will be updated for
0.10, it will likely not be updated to support features more than what
it already supplies.
Hopefully that explanation of the differences between these plugins is
helpful.
Owen
Reply all
Reply to author
Forward
0 new messages