Alfresco discussion and collaboration. Stick around a few hours after asking a question.
Official support for Enterprise subscribers: support.alfresco.com.
Join in the conversation by getting an IRC client and connecting to #alfresco at Freenode. Our you can use the IRC web chat.
More information about the channel is in the wiki.
More help is available in this list of resources.
2020-01-15 11:36:08 GMT <AFaust> oh yeay (not really)... I'll have to convert one of my transformers from legacy transformer to the new local transformer / transformer image sometime soon. Curious to see if I end up using Alfresco's transformer base or write a significantly smaller / less memory-hungry Jetty-based base myself
2020-01-15 12:02:53 GMT <angelborroy> I’m also curious ;-)
2020-01-15 15:15:24 GMT <AFaust> angelborroy: Do you know what the background is for error messages like "Local transformer names must exist and be unique (<name>). Read from resource <path>"?
2020-01-15 15:16:01 GMT <angelborroy> Not really
2020-01-15 15:16:04 GMT <AFaust> ^ 6.2.0 GA system with local transform enabled, no legacy fallback...
2020-01-15 15:16:26 GMT <angelborroy> I guess legacy fallback is required?
2020-01-15 15:18:40 GMT <AFaust> I don't think so. Legacy would be to enable the bridge from RenditionService2 to good ol' ContentTransformer API. Local transform implements plugs in the RenditionService2 framework directly and calls transformers via HTTP...
2020-01-15 15:20:06 GMT <AFaust> I mean, I just now noticed these messages on a restart without any relevant changes. And I know for sure that transformation worked fine in this new customer dev/test system this morning.
2020-01-15 15:20:37 GMT <angelborroy> That monster is still an unknown beast for me
2020-01-15 16:25:27 GMT <AFaust> angelborroy: Can you check / tell me what the reason for REPO-4619 was?
2020-01-15 16:27:52 GMT <AFaust> This is especially bad because the typo (missing $) in https://github.com/Alfresco/alfresco-repository/blob/master/src/main/resources/alfresco/public-services-context.xml#L95 means I cannot white list my caller, so have to disable the entire interceptor or override its XML...
2020-01-15 16:27:53 GMT <alfbot> Title:alfresco-repository/public-services-context.xml at master · Alfresco/alfresco-repository · GitHub (at github.com)
2020-01-15 16:29:12 GMT <angelborroy> The investigation showed that this issue is applicable to any APIs as it is how NodeService <-> ContentService interaction is handled. Unfortunately there is no embedded functionality in Alfresco which can control permissions on individual properties. As a midterm fix (until permission model is rearchitected) I tried to apply restrictions on setting a content type property on a node. The approach is to throw an exception wh
2020-01-15 16:29:12 GMT <angelborroy> code is trying to set a node property of content type directly through NodeService instead of using a ContentWriter from ContentService. The ContentService (or any other trusted service) can use an unrestricted method to set the content property.
2020-01-15 16:29:14 GMT <angelborroy> Please see the test for this issue (NodeServiceTest#testUpdateContentPermission()) and proof of this concept in this PRs:
2020-01-15 16:29:15 GMT <angelborroy> https://github.com/Alfresco/alfresco-repository/pull/565
2020-01-15 16:29:17 GMT <angelborroy> https://github.com/Alfresco/alfresco-data-model/pull/151
2020-01-15 16:29:18 GMT <alfbot> Title:WIP: REPO-4619 Restrict content property updates by killerboot · Pull Request #565 · Alfresco/alfresco-repository · GitHub (at github.com)
2020-01-15 16:29:18 GMT <angelborroy> This code changed only one endpoint that is capable of changing the properties - NodeService#setProperty, but even this broke a lot of tests: https://travis-ci.com/Alfresco/alfresco-repository/builds/123729715
2020-01-15 16:29:19 GMT <alfbot> Title:REPO-4619: Add new methods to NodeService by killerboot · Pull Request #151 · Alfresco/alfresco-data-model · GitHub (at github.com)
2020-01-15 16:29:20 GMT <angelborroy> Limitations of this approach:
2020-01-15 16:29:21 GMT <alfbot> Title:Travis CI - Test and Deploy with Confidence (at travis-ci.com)
2020-01-15 16:29:21 GMT <angelborroy> The changes to NodeService interface are not a good solution. It is hard to expose and document an internal/unrestricted/dangerous method. There might be other solutions, for example, setting a transaction resource, thread local or other markers to be able to identify a trusted call from other services when the content property can be set. This may be harder to implement reliably.
2020-01-15 16:29:22 GMT <angelborroy> The changes in any way will break a lot of tests and potentially any custom code developed on top of this functionality. This may be a blocking restriction to put that in SPs.
2020-01-15 16:29:23 GMT <angelborroy> In my opinion it will be too risky to introduce the fix in a SP, especially on such late stages. The value of it is currently based on the fact that the attacker must know the content URL, which is usually random, inaccessible.
2020-01-15 16:31:06 GMT <AFaust> Too bad that the only way to copy content without doing a full copy or duplicating content on disk is by setting the content properties selectively...
2020-01-15 16:31:22 GMT <AFaust> Ok - stupid feature, going to disable it...
2020-01-15 16:32:28 GMT <AFaust> Devs from Engineering should be made to work in the field every so often...
2020-01-15 16:35:59 GMT <AFaust> "copy content" => "reuse existing content reference / files"
2020-01-15 16:44:01 GMT <AFaust> Though I still do not yet understand the main reason behind it.
2020-01-15 16:44:08 GMT <AFaust> What does this have to do with permissions?
2020-01-15 16:44:44 GMT <AFaust> Ah right - you don't have writeContent permission, but can "write content" by setting the property via the NodeService...
2020-01-15 16:47:12 GMT <AFaust> I really "love" these overly aggressive short-term "fixes", which are not documented and slip in as part of service packs / hotfixes (I see this has been merged into the Enterprise 6.0 line as well). It was already fun to have a similarly aggressive change with workflow / task access in 4.1.5 years ago...
The other logs are at http://esplins.org/hash_alfresco