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 <javascript:>>
> 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 <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.
