Vulnerability in EPiServer.Forms
Can anyone please tell me wether it's possible or not, to use the property called "Link Collection" with editable="true" editmode="true" from <episerver:property.../> !? It seems like it would work, i can see all the buttins and a list of links ( made from backend-editmode ). BUT when i click for example the "Add Link" button I get an js-error. ( 'EPi.ToolButton' is null or not an objekt ). Does anyone have some idéas for a rookie like me!?
I'm using EPiServer CMS 6
Ops... didn't mention that... Yes I'm a member of administrators group... ( the same as is allowed to edit that field in back-end-edit mode )
I suggest you use a developer toolbar and/or fiddler to find out what causes the script error - problems loading a resource etc.
Note: To answer your first question, I'm not sure you can use the editor at all. But when using the XHTML editor there have been problems with script access which can be resolved and make the XHTMl editor work.
I've already done that. Fiddler tells me that everything that browser asks for is downloaded allright. ( Even if i flush cache and tries again it all comes down ).
Developer toolbar tells me, that EPi.ToolButton is undefined ( when i hover the Add button ), and if i click the button it tells me, EPi.CreateDialog is not a function.
And yes, I have tried xhtml properties and longstring and so on... all working, but this one's got more logic...
Try adding explicit script references to these files to the page.
ah... nice one kick in some kind of direction :D
Had to add system.js and change path to system.aspx
Now it's working... BUT... now i gonna get security issues i think...
AND why is those script not included in the first place!?
Ah, I looked at the R2 beta where the system.js and system.aspx are in the util folder, probably for exactly that reason (since util is not protected like the UI folder is).
The scripts are included when you do quick edit etc which is what the edit mode of the property is mainly intended for. But I agree, if the scripts can be somehow encapsulated in the control or injected by the control it would add value in situations like this.
That shouldn't mean you are doing anything dangerous security-wise (as I said, the js files are moved to an open location in R2).
I agree that it should make sure that the files are loaded and I've added a bug report for this. Since there is a work around for this I don't think that the fix will make it to the R2 release so you'll have to live with the work around for now.
Using this thread with another question in the same area.
Ok... now I've implemented that work-aronud. It seems like it works, I can update/change links as i suppose to... BUT ... when I submit page and looks att the property from code behind. like this
they all got the old value, without my designtime changes. Is this part of this issue too?! or am I looking at wrong values?
Is this a built in page property? If so, have you set CurrentPage to a writable clone?
it's not alot of code to save... so here it is.
CurrentPage = CurrentPage.CreateWritableClone();CurrentPage["Links"] = Links.PropertyValue;//.InnerProperty.Value;//Links.PropertyValue;DataFactory.Instance.Save(CurrentPage, SaveAction.Publish);Response.Redirect(CurrentPage.LinkURL);
It's just the propertyvalue that goes wrong... if I change the LinkItemCollection by code back here and saves it saves with the proper values, BUT man "design-time" values are gone...
You need to create the writable clone early in the page load cycle. What happens in your scenario is that the property control gets a reference to the non-writable version of the property and when it tries to update it it fails. I usually set CurrentPage = CurrentPage.CreateWritableClone() in page init when I know that I have page properties in edit mode.
aha... I thought it was made automatically when setting <episerver:parameter editable=true ... />