> >Some time ago, I extracted the remote publishing code of > wiab and put > >it aside for testing. I have used the code in some project > so I guess > >it is back at the same stable level as it was in wiab. I could email > >you the code if you want. I might add this code to the > MMBase cvs when > >I have some time and a internet connection available (I am > now behind > >very well maintained firewalls). > > Hi Nico, > > Have you loked at the possibility to use workflow/node cloning on a > single mmbase cloud using security to hide the data on the frontend?
Yes, I did. A couple of months ago, I made a small demo for a customer to show what was possible with workflow. You can use the cloud context security model with one publish context for the anonymous user. With workflow you have to make a difference betweeen workflow security and object security. Object security: is this user allowed to read/write/delete/link the object? workflow security: is this user allowed to write/delete/link the content element when it is in state draft/finished/approved/published? The first security is about objects and the second one about content elements. Content elements are objects, but an object is not always a content element. A site has administrative objects (users, jumpers, properties, emailqueues) to implement features. In my view, MMBase is a content engine which stores and retrieves objects. It does not have a clue what a content element is. Logically, MMBase can only do object security. Other CMSes know the difference, but they define which administrative objects are available. Web-In-A-Box has workflow security. It defines which content types are content elements. A block of content elements can have a workflowitem attached to it. The workflowitem is attached to one content element and the other content elements have relations to that content element. Web-In-A-Box is from the days that there was no decent per object security. As you know, hiding the data with a context was not possible. The multi-cloud solution is a good option. Now the context security is good in per object security. WIAB does a remote cloud publishing operation at the end of the workflow, but this could also be a ccontext change. It does not even take a lot of time to do that I guess. I still prefer the multi-cloud solution, because then the object security can be used for editor authorization on objects in the staging cloud. Some time ago, at a brainstorm session at Finalist, we came up with an idea to run multiple wiab ionstances in one mmbase cloud. Every instance would get his own context. The live cloud could run without any security, because that contains only published content. The frontend will be very fast and you can guarantee in the staging cloud that nobody can alter the objects of another wiab instance. Nico Klasens --------------------------------------------------------------- My programs never have bugs, they just develop random features.
