Thanks for the suggestions Dan.
This is probably misguided, but I thought it may be a plan to have a double
check for view rights before loading the page. In other words check for
auth.view, but if that *fails* then check for auth.invites. This will
allow higher up levels of rights to remain in place and only allow invites
as a fallback/addition.
I made an attempt to alter BOLTloadpage in library.php, but my php skills
are sorely lacking so I could not figure out why the following does *not*
work:
Right at the top of the BOLTloadpage function in library.php
if (function_exists('myBOLTloadpage')) return myBOLTloadpage($page, $dir,
$data, $auth);
if ($auth) {
global $BOLTid;
if (BOLTauth($page, $BOLTid, 'view') == false) {
if (BOLTauth($page, $BOLTid, 'invite') == false) return;
}
}
The file auth.invite follows the same pattern as auth.view
Any thoughts?
On Friday, 12 February 2016 16:37:55 UTC+2, Dan wrote:
>
> How secure do you want it to be?
>
> One solution would be to use a conditional in the header that says
> something like
>
> [if ! inpage blueteam.roster {id} && ! inlist {p}:guest_read
> {id}]<(forward action.blocked)>[if]
>
> You can then leaven the groups open to view for all logged in members, but
> only those on the roster page or in the pages guest_read var will be able
> to actually see it. Others would be forwarded away.
>
> The reason I ask about security is a user could go to another page they
> had edit permissions on and do an include to view the contents. Because
> technically they have view permissions, BoltWire would supply the page.
>
> I don't have an immediate solution for doing what you want to do, because
> as soon as you set specific permissions for a person on site.auth.view for
> a specific page, it will overwrite the general view permissions for that
> group of page. I suppose you could do in your guest_read form, something
> like:
>
> [if ! set {site.auth.view::{p}]
> [command info page=site.auth.view field={p}
> value={site.auth.view::{p1}.{p2}},{=newid}]
> [else]
> [command info page=site.auth.view field={p} value=+{=newid}]
> [if]
>
> Basically this copies over the default group settings to the specific page
> setting the first time. Afterwards, it just adds new members. The problem
> is if you change the group settings you have to reset all the specific page
> settings.
>
> Maybe someone else has a better solution...
>
> Cheers,
> Dan
>
> On Fri, Feb 12, 2016 at 8:12 AM TMurNGon <tmur...@gmail.com <javascript:>>
> wrote:
>
>> Hi Dan,
>>
>> I have an interesting requirement that I am not sure how to solve:
>>
>> Say I have a number of user groups (each with their own page hierarchy),
>> for example blueteam and redteam.
>> It is easy enough to set view and write access for each group in the
>> current auth pages.
>>
>> But what if, on a page by page basis, a blue team member wanted to grant
>> guest viewer or guest writer privileges to a red team member (for blueteam
>> pages)? Keeping in mind that the red team normally have neither read nor
>> write access to blue team pages.
>>
>> I'd like the blue team member to be able to add a data field with a
>> specific name (guest_read? guest_write?) containing the guest users id (or
>> even a guest group id); resulting in the named users or groups having read
>> (and maybe write) access to the page in question.
>>
>> Another way would be to have some new auth pages (eg. auth.guestread or
>> auth.guestwrite) which would function in a different way from the ordinary
>> auth pages in that they do not completely override higher up level auths,
>> but simply add the members or groups specified to the existing auths
>> (auth.read and auth.write). That way the additional folks can be added
>> (and later removed) without interfering with the standard setup.
>>
>> Not sure I have explained that sufficiently..., but I just cannot figure
>> out a way to do this...
>>
>> Any ideas?
>>
>> Thank lots.
>> Jan
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "BoltWire" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to boltwire+u...@googlegroups.com <javascript:>.
>> To post to this group, send email to bolt...@googlegroups.com
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/boltwire.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to boltwire+unsubscr...@googlegroups.com.
To post to this group, send email to boltwire@googlegroups.com.
Visit this group at https://groups.google.com/group/boltwire.
For more options, visit https://groups.google.com/d/optout.
