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 <tmurn...@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+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.
>
--
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.
