Hi Dan,
Thanks very much. This does indeed seem like the solution to my problem.
I will give it a go.
On Thursday, 18 February 2016 18:23:50 UTC+2, Dan wrote:
>
> Ok, I think I have a solution for you...
>
> First, you are correct, you must use mypage*. The auth pages do not
> recognize the mypage.* syntax. That's just in searches.
>
> Second, I doublechecked your code modification to the BOLTloadpage
> function, and discovered the problem is not there at all, as it generates
> the correct value. Rather the page load is being blocked somewhere else.
> Most likely the BOLTpageshow function (library.php, ~1414). And possibly
> other places as well. I didn't feel quite comfortable with this approach as
> there may well be still more places you would have to write variations in
> the code to get it all to work, so I didn't explore this approach much
> further.
>
> Rather, I decided to try a different approach similar to the authkey
> command, which grants temporary access to a group. So here's my setup. On
> site.auth.view:
>
> docs.red*: @red
> docs.blue*: @blue
>
> Then in docs.invites I create a list like:
>
> docs.red.note1: bob,dave,mary
> docs.blue.note2: mary
>
> Ok, now suppose bob is in the blue group but not the red group, and mary
> is not in either group. What we want is to temporarily add bob to the red
> group if viewing docs.red.note1 and mary if she is viewing either of the
> two specified pages. So what I did was add the following lines to my site
> config.php file:
>
> if ($pageArray[0] == 'docs') {
> if (inlist($BOLTid, BOLTvars("docs.invites::$pageLink"))) $BOLTgroups =
> $BOLTgroups . ",$pageArray[1]";
> }
>
> Basically it first checks to see if it is a docs page, and then if it is,
> scans the docs.invites page to see if the user has a valid invitation for
> the current page. If so, it adds the group permissions to group {p2}
> temporarily.
>
> I've tried this briefly on my system and it seems to be working fine. It
> doesn't allow for source or includes even by invited users to other
> sections of the site because they lose that permission as soon as the go to
> any other page.
>
> On the plus side, this gives the user any other permissions of the
> red/blue group, such as leaving comments or making uploads, or edits, or
> whatever else you allow them to do, which is what you want I believe. On
> the small down side, if bob has edit permissions on docs.red.note1 he
> could include docs.red.note2 to it because he has temporary read access to
> the red group via the invite to note1. But even this is probably a good
> thing, because it means bob will see the docs.red.header, ..footer, ..side
> menu, etc, when he visits ..note1--which would otherwise be blocked to him.
> Security
> can be pretty tricky sometimes...
>
> You can use normal BoltWire functions to add and drop members to the
> docs.invites page. And you'll need to manually create the site.auth.view
> entries for each docs group.
>
> Let me know how this works for you.
>
> Cheers,
> Dan
>
> On Thu, Feb 18, 2016 at 5:42 AM TMurNGon <tmur...@gmail.com <javascript:>>
> wrote:
>
>> Hi Dan,
>>
>> In order to proceed a bit more systematically, I am just trying to set up
>> some examples with ordinary (view,write) auth applied to see that the
>> standard setup works first. When that all works I will try out the invite
>> auth again.
>>
>> Am I correct in saying that the following works in auth.view:
>> mypage*: @bluegroup
>> but that the following does *not* work:
>> mypage.*: @bluegroup
>>
>> This is what it seems like in my testing anyway...
>>
>> By the way: the credentials I gave you previously for my test site still
>> works if you want to take a look.
>> The 'notes' section (blue and red) in particular is what I am basing the
>> test on (see member.bob as an ordinary member of blue group - which, apart
>> from the invite to notes.red.note1, should not have access to red group
>> notes)
>>
>> Thanks.
>> Jan
>>
>>
>>
>> On Wednesday, 17 February 2016 18:22:41 UTC+2, Dan wrote:
>>
>>> So to clarify, what happens with the various scenarios:
>>>
>>> view permission, but not invite permission?
>>> invite permission, but not view permission?
>>> both view and invite permission?
>>> neither view or invite permission?
>>>
>>> This might help narrow down where the problem is... Also are you using
>>> groups and/or individual ids on your site.auth pages. Wouldn't mind seeing
>>> your auth settings...
>>>
>>> Another solution might be to use toolmapping and create a custom
>>> include/source function just to close that avenue of attack and go with my
>>> initial suggested approach. Relatively easy to do. Let me know if you need
>>> help using toolmapping....
>>>
>>> Cheers,
>>> Dan
>>>
>>> On Tue, Feb 16, 2016 at 4:56 AM TMurNGon <tmur...@gmail.com> wrote:
>>>
>>>> Hi Dan,
>>>>
>>>> I've followed your suggestions above, but no luck. I just receive a
>>>> notice from view action saying:
>>>> "Access Blocked
>>>>
>>>> This page is not available or you may not have permission to perform a
>>>> requested action on this page."
>>>>
>>>> The issue is unlikely to be with the entry in site.auth.invite because
>>>> when I copy the line from this file into site.auth.view it works as
>>>> expected.
>>>>
>>>> It looks like it is not accessing the entry in site.auth.invite.
>>>>
>>>> Initially I thought it may be because I have my site.auth files in a
>>>> sub folder, but all other site.auth pages work and there is no success
>>>> even
>>>> when I move it to the pages folder.
>>>>
>>>>
>>>>
>>>> On Monday, 15 February 2016 22:00:31 UTC+2, Dan wrote:
>>>>
>>>>> This was a good idea...
>>>>>
>>>>> How exactly is it failing? Seems like it should do what you want it
>>>>> to. My guess is something is not right in your site.auth.invite page? You
>>>>> could also try changing it like this just to check if there's a logic
>>>>> problem you and I are both missing:
>>>>>
>>>>> if (BOLTauth($page, $BOLTid, 'view') == false && BOLTauth($page,
>>>>> $BOLTid, 'invite') == false) return;
>>>>>
>>>>> If you go this route, be sure to use the web hook for this function.
>>>>> That is, copy the entire BOLTloadpage function to config.php, then change
>>>>> the name to myBOLTloadpage and delete the first line of the function.
>>>>> Then
>>>>> modify the function as you want. It will be used instead of the core
>>>>> system
>>>>> function. The advantage of this is the next time you upgrade, your
>>>>> changes
>>>>> to the function will not be overwritten by the new release, and you won't
>>>>> have to re-edit it with every upgrade.
>>>>>
>>>>> Don't really have time to debug this more fully, but I think you are
>>>>> on the right track. Let me know if you can't make any progress.
>>>>>
>>>>> Cheers,
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Feb 13, 2016 at 2:08 PM TMurNGon <tmur...@gmail.com> wrote:
>>>>>
>>>>>> 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> 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.
>>>>>>>> To post to this group, send email to bolt...@googlegroups.com.
>>>>>>>
>>>>>>>
>>>>>>>> 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+u...@googlegroups.com.
>>>>>> To post to this group, send email to bolt...@googlegroups.com.
>>>>>> 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+u...@googlegroups.com.
>>>> To post to this group, send email to bolt...@googlegroups.com.
>>>> 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+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.
