As to the security issue, to me it doesn't seem much different than it is now. If the host allows a portal to upload a skin then what's the difference whether the scripts are in the html or ascx? If the host doesn't allow portal skin uploading, then nothing is different anyways.
On a side note related to security, how do hosts that allow FTP access to the portal mitigate the security issues related to a portal admin being able to upload a skin into the portal that way? Is there a scheduled task that deletes any rogue folders that show up under the skins and containers folders? Given that, how does DNN respond to a folder that suddenly appears within the skin or container folders? From what I've seen, on an unmodified DNN install, it just adds the new folder to the portal-level skins available- so that seems to be more of a security risk than what I've requested. Because, even if the host disallows skin uploads by the portal but gives the admin ftp access to the portal root, skins can be uploaded and this whole issue of scripting in html skins becomes a moot point.
That's my take anyways.
For those interested-
This issue was brought up because I wanted an easy way to design an HTML skin that would display the portal name as a text-hyperlink IF the portal did not have a logo image defined. What sounds like a fairly simple IF-THEN statement turned into something a bit different since the parser re-wrote the URL in the anchor tag to reflect the skinpath instead of the portal's root. This caused the skin to not be displayed at all. The discussion turned to (dis)allowing the skinner to upload a pure html skin with server-scripting.
The initial rationale for not changing anything was that if anyone wanted to use scripts, the person should use ascx. Fair enough. But if I can do it in html anyways, what's the difference? For me, being able to view the skin as html is easier. I can preview it in my browser from the editor and see fairly well what my scripting will do, save for content panes, skin objects, etc and menu styles, what it will look like without uploading it. By editing in ascx, I'd have to link style-sheets, edit image paths, etc. with every modification I made just to be faced with undoing the changes to upload the skin. Also, editing in HTML allows me to edit the skin in-situ on the server then when I actually want to see what DNN will do it it, I just reparse it and DNN handles the changes to ascx (my server is physically local). To be honest, what's the difference between what I want to do and any designer using a RAD environment to create an application (like DNN for instance)? Was DNN hand coded line-by-line or did someone use automated tools to turn it into the final product?
Before going further, I just want to say that I am not talking about compiled .net controls, etc. Obviously, that should be done through skinobjects and tokens. I'm talking about server-side scripting like asp or php used for more benign purposes like the logo / text link swapping I mentioned earlier.
One thought I had about how the parser could recognize scripts could be something like a token bracketing the script. For instance:
[BEGINSCRIPT]<% scripting code in here %>[ENDSCRIPT]
When the parser encounters the opening token, it just quietly ignores the following text until it hits the closing token, much like comments are ignored- the parser has to skip over those as well so the parser source code would probably just need an extra condition to recognize the scripting tokens in addition to the html comment delimiters. This would break nothing about the parser's current method of operation nor break existing skins. It would not have to hit the XML to parse anything any more than it does now. That is unless the skin team wants to allow it to parse another token or skinobject within the script.
Alternatively, the parser could be re-written to completely block any scripting and force everything related into the ascx skinning method.
This could open up what I feel would amount to increased flexibility for presentation within the skin. DNN's public properties are already exposed so something as simple as my logo idea would be cake. Taken even further, one skin file could handle multiple menus or layouts based on a users role without having to set permissions on each module.