Why is this unsafe? You do have the same security mechanisms that apply to Magnolia in general. Simply restrict the rights to this specific area which is updated by the user anyway. Or deny access completely and have the superuser activate the content back to author.
It is not unsafe as "everybody can destroy everything from home with a couple of clicks", it's more like "it works fine, but if I overlook something non-trivial it could be really bad". I always thought the public instance as a disposable machine. A machine that can be hacked or die without affecting the others in the internet. We hope that this doesn't happen, but it's a machine exposed to the net and I like to be sure. The "standard" public instance of Magnolia exists without even knowing there is some author instance somewhere, and can be set up as almost completely separated from the intranet. In this situation any content can be overwritten by author instance. If you implement a slightly different version of backpublishing for each of your site (customizing it every time), there may be some bugs here and there, but if backpublishing is implemented as standard UGC handler and there is a security bug, all of the author instance may be affected. Also you are creating a sort of circular reference between the two instances. I think you implemented the backpublishing action on save handler, but someone can also implement it with a modification listener, and if there is another similar listener on authoring there will be an infinite circle of publications... It seems (theoretically) to lose one of the strong point of separated public/author instances.
I don't see the great danger of concurrency problems either. There is only one scenario that I can come up with, where we would actually have a concurrency problem:
And this is exactly the scenario I had in mind.
a) this would be quite a coincidence, right?
Concurrency coincidence happens! An quite often indeed. I hope your websites have more than zero users... :-) Usually the user writes to the page something like "This r0ckz!" in a few seconds or less, while the editor is double checking the spelling and readability of all his text in the page for the whole morning, asking his colleagues a better rephrase of a few pieces. Nothing so bad in losing a few comments here and there, but systematically losing pieces of the website is not a good policy anyway.
b) it could be fixed by a custom save handler of the dialog which compares modification dates. Tricky but feasible I would say.
The separation by design may help in most cases, until client's requirement and business logic don't kick in something. First reasonable example that comes in mind is that the user can edit his/hers own email, and the admin can also do that when password recovery fails. So the email field won't fit in Jan diagram without a couple of tricks (maybe duplicated fields with the same name in the two branches, with loading priority). And by the way, it happened to me that a user closed the mail account and forgot both password AND username... :-)
The "Backpublishing" option is the best IMO, if you actually need the content on the author instance that is. I like this solution because it is rather easy to set up and it is fully consistent with the Magnolia setup. But maybe I'm really missing something, so I really appreciate this discussion.
We are discussing just to see if there is a general one, and everybody is proposing the solution that fits better with his clients' requests and problems encountered. I even started doubting the solution I advised (dedicated UGC repo set but clustered between author and public) is really fit for all cases...
Regards, Danilo. ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
