3 Replies Latest reply on Sep 24, 2014 5:46 PM by noelwhite

    Search API returns 403 if any place listed blocks access

    noelwhite

      In our 7.0.2.0 instance, we are doing a multiple container search using the search API.  We are finding that the following search works:

       

      https://jive.site.com/api/core/v3/search/contents?filter=place(/places/362272,/places/380254)&filter=search(test*)&count=5

       

      It returns a 200 with valid search results.

       

      but the following search that simply adds an additional place to search:

      https://jive.site.com/api/core/v3/search/contents?filter=place(/places/362272,/places/380254,/places/368954)&filter=search(test*)&count=5

      returns a 403 Forbidden as the user is not authorized to "/places/368954".


      Since both calls have the authorized places "/places/362272" and "/places/380254", the second API call should not fail with a 403.  It should search through all of the authorized locations and return what results are found in those.

        • Re: Search API returns 403 if any place listed blocks access
          DominicG

          I had the same issue.

           

          If you search specific places, the user must have access access to each of the places. Otherwise, it throws an error. We would much prefer it not search the inaccessible place(s), and continue searching the rest.

          • Re: Search API returns 403 if any place listed blocks access

            In my opinion, the current behavior (return a 403 if you ask for content from a place you are not allowed to access) is the correct answer:

            • It is consistent with any other API call that tries to access the place or the content in it (they all return 403s).
            • It is a clear indication that you explicitly asked for something you are not allowed to access (versus, say, a search that doesn't have any place criteria, where the system does silently filter out matches you are not allowed to see).
            • It avoids the very misleading alternative of not letting the caller know they tried to do something that was disallowed.

            Note that an API caller can easily tell whether they have access to a particular place by trying to access that itself (GET /api/core/v3/places/368954).  If you're not allowed to do that, then the client application should not include that place in its filter criteria.

              • Re: Search API returns 403 if any place listed blocks access
                noelwhite

                I disagree with your assertion that this creates consistency:

                • The search API without any place specification uses entitlements to filter unauthorized places.  This should do the same to be consistent.
                • I fail to see the clarity of the 403 when the user actually DOES have access to some of the places?
                • Return packets are great at returning additional information to applications, such as "unauthorized: /places/368954".  HTTP return codes are inherently lousy at it, as this conversation demonstrates.

                Your suggested work-around does provide an answer to getting an authorized list of places, at the cost of MANY more API calls.  This makes for solutions that do not scale well.