Hi,

This seems to be caused by the use of NeatHtml to prevent cross site scripting.

At first I thought it was because the smileys are being served from beneath the ClientScript folder and I thought maybe the word script as part of the path was triggering some blocking, but I tried moving the smileys to a different location and still get the same result.

Hopefully Dean Brettle (the author of NeatHtml) will see this post and offer a solution or suggestion.

Dean, are images not allowed in untrusted content?

Thanks,

Joe

Thanks Dean.

I don't see this as an urgent issue so just let me know when you've completed those enhancements and I'll upgrade to your new version of NeatHtml.

Best,

Joe

Hey Dean,

I posted a bug in your forum for the new version. It seems the TrustedImageUrlPattern must be set or an error occurs in mojoPortal. Its not a serious bug because I can set it everywhere its used, but seems it should not error without making a specific setting. Also if there is any mistake in the regex pattern it throws an error. Maybe this is what it should do but maybe it should just fall back to not allowing images or display a message like it does if it can't find the .js file.

Also, I'm not the best at regex expressions was wondering if you could illustrate a pattern for allowing any images from any site and a pattern that allows images only from within the site?

For example, in the Community Blogs page (RSS Aggregator), I'd like to allow all images because I'm only aggregating relatively trusted feeds.

In the Forums, I'd like to allow images from anywhere within the site, but not external.

Thanks,

Joe

Smilies are working again. Thanks Dean!

Hi Dean,

No, I went through and found each use and set it either declaratively or in code. For the RSS Aggregastor I added a module setting whether to allow external images. For the forum and blog comments I only allow relative image urls.

To me, while it is possible to set non visual properties on server controls using theme.skin, I think its not a great idea particularly for security settings. theme.skin files are conceptually for visual styling. It would be a maintenance problem to go through all the skins in mojoPortal and add this setting and also people who already have custom skins would not benefit from the security because their theme.skin file would not have this setting. So it seems a problem to lose security if the skin is changed and therefore doesn't seem like a great practice to use it for the UntrustedContent control.

When 2.0 .NET came out, I went to great efforts to be able to relocate the theme.skin file into the site specific skin folders instead of the App_Themes folder and finally got it working. But since then I have realized that theme.skin is really not a good way to set visual properties either because it creates inline style in the markup and bulks up the size of the page. So really at most its useful for setting css classes.

The only other good use I found for theme.skin is for a CornerRounderTop and CornerRounderBottom controls which just  renders extra divs that can be used in conjunction with css to style rounded corners. I use a theme.skin property to tell the control whether to render or not so if the skin doesn't use corner rounding the extra markup can be left out.

The other issues I've been contemplating about untrusted content is how to allow untrusted users to post rich content like YouTube videos, Flash, etc. Currently in mojoPortal users who have access to the Html module are considered trusted whereas forums and blog comments are not. So in the Html module its possible to add YouTube videos etc. It seems some would like to use mojoPortal to build social sites where users can create all kinds of content and may not be particularly trusted. So the challenge sems to be infiguring out a right balance that doesn't allow the site to become a malware playground like MySpace yet still enables rich social interaction and content.

Best,

Joe