Velocity: how to check if user has right 'view'

Help / Discuss
1

Hi.

I have some code that worked for a long time. Currently this line isn’t working anymore. I query for all changed articles and will list them as a table. But I wan’t to show only those results that the current visiting user is allowed to view:

#if($xwiki.hasAccessLevel('view', $xcontext.user, $recentDocResult))

We are at XWiki 17.4.4 now. I’m quite sure it worked with 15.10.13.

Is the code line above valid?

Regards, Simpel

2

Hello,

Just tested the following on XWiki 17.7.0 and it works fine:

{{velocity}}
#if ($xwiki.hasAccessLevel('view', $xcontext.user, $doc.documentReference))
  Works!
#end
{{/velocity}}

What doesn’t work?

3

Thanks. adding .documentReference fixed it.

#if($xwiki.hasAccessLevel('view', $xcontext.user, $recentDocResult.documentReference))

I iterated the returned query object with #foreach($recentDocResult in ${recentDocs}). And it did work long versions ago without adding .documentReference.

4

@Simpel I don’t think we changed that API.

You can try it yourself:

{{velocity}}
$doc.toString()
$doc.documentReference.toString()
{{/velocity}}

Gives (on my page where I tried it):

Main.test.WebHome
xwiki:Main.test.WebHome
5

Maybe it’s more that your use case has changed and before $recentDocResult was pointing to a page in the same wiki and it’s now located in another wiki?

7

Note that $xwiki.hasAccessLevel is actually quite legacy and will be explicitly marked as deprecated one day.

The current standard would be more

#if($services.security.authorization.hasAccess('view', $xcontext.userReference, $recentDocResult.documentReference))

or just

#if($services.security.authorization.hasAccess('view', $recentDocResult.documentReference))

which assumes you are checking the context user.

8

Tested:

    #foreach($recentDocResult in ${recentDocs})
        $recentDocResult.toString()
        $recentDocResult.documentReference.toString()
    #end

Results:

[Ljava.lang.Object;@1330a544
$recentDocResult.documentReference.toString()
[Ljava.lang.Object;@4dcb0313
$recentDocResult.documentReference.toString()
[Ljava.lang.Object;@e2aab68
$recentDocResult.documentReference.toString()
[Ljava.lang.Object;@541875ca
$recentDocResult.documentReference.toString()
[Ljava.lang.Object;@f32f5ca
$recentDocResult.documentReference.toString()
[Ljava.lang.Object;@26963c15
$recentDocResult.documentReference.toString()

Guess my query is somewhat faulty? I see opening square brackets but no closing.

The querying page and the pages pointing to are all in the same sub wiki.

9

Changed that to be future proof. Thanks.

10

Btw what language did you choose for the code format? I can’t find velocity in the drop down menu and my first approach ‘java’ didn’t fit.

11

This means that recentDocResult is not of type Document but it’s an array of objects.

Noe: Don’t know if it’s your issue but if you do a XWQL SELECT you’ll get a list of object arrays.

12

None

13

Hi, sorry to dig this out but im currently have a lot of trouble about access checks via velocity in a very special rights situation. that too is about checking if user has right “view” on a page.

But both the ways (legacy and modern way) to check seems to fails in my very special rights configuration:

UserA and UserB are in XWikiAllGroup (I guess it would be the same if we would use manual created group)
UserB is in GroupB
Also UserB is Admin (should not matter in this matter)

  • TopPage - View right for XWikiAllGroup, view and edit rights for GroupB, both set in rights for page and subpages
    • MediumPage - Again: view and edit rights for GroupB, set in rights for page and subpages XWikiAllGroup has therefore no rights at this step anymore, However the XWikiAllGroup has additionally set rights for page (but not subpages) and therefore still can view this .WebHome
      • multiple more secret pages - no explicit rights are set and the rights are inherited from above, UserB can view and edit in these, but UserA dont’t even know these exists.
      • NotSoSecretPage - View right for XWikiAllGroup, view and edit rights for GroupB, both set in rights for page and subpages
        • TargetPage - no explicit rights are set and the rights are inherited from above.

Fact: UserA can navigate to and view TargetPage as that ones inherits the rights from the above NotSoSecretPage where he has gotten ViewRights.

Reason behind this strategy: UserB can view and write on all these pages, and only the minimum amount of rights must be set ONCE, and all additional pages that UserB creates below MediumPage are protected besides NotSoSecretPage which should be viewable by all.

Now we come to the bug/bugs:
With the Navigation Macro, UserA can navigate down every step - even directly on “MediumPage” can be clicked - once he is down at NotSoSecretPage or below however, he cannot click on “MediumPage” in the breadcrumbs - that is grey? This is just something noteworthy that is maybe related to the main bug I am facing?

My suspicion is, that it maybe is related to the issue and the breadcrumbs too fail to create the link because some rights checks failing, which brings me here:
I need to check via Velocity if user A has view access rights to TargetPage.
But both the the legacy or the newer function tells false. - even though he can indeed view that page?

It gets even more confusing:

  • If I check the same with UserB, it also is false?
  • If I test both for “MediumPage” - both are true.
  • Any page below “MediumPage” - test returns false for both.

here the small test velocity script that breaks as soon as “MediumPage” or below is tested.

#set ($document = $xwiki.getDocument("TopPage.MediumPage.NotSoSecretPage.Targetpage")
To see if document is found:
Document: $document


#set ($docReference = $document.documentReference)
To see if document reference is found:
DocumentReference: $docReference


#set ($userDoc = $xwiki.getDocument('XWiki.UserB'))
To see if user is found:
UserDocument: $userDoc


#set ($userObj = $userDoc.getObject('XWiki.XWikiUsers'))
To see if userobject is found:
UserObject: $userObj


#if($xwiki.hasAccessLevel(‘view’, $xcontext.userReference, $document))
view rights via legacy check
#end

#if($services.security.authorization.hasAccess('view', $xcontext.userReference, $recentDocResult.documentReference))
view rights via modern check
#end

So it appears that the rights stuff results in breaking of velocity checks?
And maybe the same issue is somehow explaining the breadcrumb issue too?

None of these pages are terminated ones, and all paths all the time show a a valid DocumentReference.
Our XWiki Version is 18.3

I would really appreciate if you could try to reproduce and tell if its a bug or if i doing something wrong!

Thank you and best regards

Tom