nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

search without acl

ale

i need to develop a kind of fast search service. the ideal situation is:

a group X
a space Y

group X can see all documents in space Y so i don't want to care about ACL when searching - the main goal is: "it has to be super fast".

i tried creating a bean that link "fileFolderService" becouse i saw that "FileFolderService" is, indeed, a proxy.

i suppose that "fileFolderService", not being proxied, would have skip alla ACL controls. it's not so: i tested it putting a break point in ACLEntryAfterInvocationProvider.decide

what's the most high level service i can use to query the repository for node without firing ACL evaluation?

thanx!

Find more posts tagged with

Comments

mark_smithson

The ACLs are applied in an aspect.

Normally search are performed by getting a search service from the serviceRegistry. It you search using this, then ACLs are applied. Internally this search service delegates to the bean "indexerAndSearcherFactory". If you get a searcher from that then the ACLs will not be applied.

SearchService searcher = indexerAndSearcherFactory.getSearcher(storeRef, !params.excludeDataInTheCurrentTransaction());
results = searcher.query(params);‍‍

We saw a reduction in times from 2-3 seconds to 10-20ms for the searches we were performing.

ale

thank you very much! from 2-3 secs to 20-30 millis is a great improvement!

i hoped in a higher level service but i'll work on that.

thank you again for "it's in an aspect" suggestion - if you have more informations about it they are welcome!

ale

in the end i made a very simple test. i created a space with 500 docs and perform a simple search like "give me all first level children" using:

fileFolderService.listFiles and then calling getName
searchService.selectNodes and then calling nodeService.getProperty for name (searchService=indexerAndSearcherFactory.getSearcher)
searchService.query (filtering on type and primary parent) and then calling nodeService.getProperty for name (searchService=indexerAndSearcherFactory.getSearcher)

the components i linked to my bean are:

"fileFolderService"
"indexerAndSearcherFactory"

then i create two users: "test" that can see all documents in the space and "guesttest" that can see ONLY one document.

using "guesttest" (first call, to be sure the cache is empty)

fileFolderService.listFiles i get 501 results in about 4 secs
searchService.selectNodes i get 501 results in about 3,5 secs (50 millis without nodeService.getProperty

)
searchService.query i get 501 results in about 4 secs (75 millis without nodeService.getProperty

)

so i suppose no ACLs are applied using these services.

just to test, if i link "FileFolderService" (the public one) as fileFolderService i get 1 result in 13 secs the first call!

hope this helps

ciao,

mark_smithson

75 millis without nodeService.getProperty Smile

Yes - there is a difference between getting a property value from the node service, this accesses the DB and may apply ACLs again to just getting an indexed property value from the search results.

andy

Hi

Bean names starting with an upper case include transaction and security interceptors, others do not. So ….

SearchService - applies acls
searchService - does not
NodeService - applies acls
nodeService - does not
…

Remember to wrap calls in User transactions to beans that do not have a TX wrapper.

Andy

ale

I can't understand why unsing faces beans ACL are applied even if they link nodeService instead of NodeService (if i'm not wrong).

caio,