This project is read-only.

2.0.38 mdo:service security

Jan 18, 2011 at 12:30 AM
Edited Jan 18, 2011 at 1:24 AM


after installing the new version some of my calls to mdo:services are now failing. Still have to check deeper, but:

  • I see new params are necessary to call mdo:services (tabid and tmid)
  • if I get the service url from mdo:service-url (I usually do) and manually test the url, I can correctly see expected data
  • if I manually set the url (e.g. in module configuration: I often call services from other modules) without some param, I now see 500 errors (access denied?)
  • mdo:node-set fails loading data from mdo:services even if url is correct and there are no restictions on module permissions
  • document() load on the same url gives an exception 
  • more details asap!
<xsl:variable name="mediaSourceURL">
	<xsl:value-of select="concat(mdo:HTTPAlias(),mdo:service-url('GetMediaSource'))"></xsl:value-of>
<xsl:variable name="mediaSource" select="mdo:node-set($mediaSourceURL)"></xsl:variable>



document load exception:

System.Xml.Xsl.XslTransformException: An error occurred while loading document ';mod=805&amp;tabid=206&amp;tmid=655'. See InnerException for a complete description of the error. ---&gt; System.Net.WebException: The remote server returned an error: (500) Internal Server Error.<br />   at System.Net.HttpWebRequest.GetResponse()<br />   at System.Xml.XmlDownloadManager.GetNonFileStream(Uri uri, ICredentials credentials)<br />   at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials credentials)<br />   at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn)<br />   at Findy.XsltDb.MdoResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn) in c:\inetpub\wwwroot\\App_Code\XsltDb\XsltDbUtils.cs:line 1560<br />   at System.Xml.Xsl.Runtime.XmlQueryContext.GetDataSource(String uriRelative, String uriBase)<br />   --- End of inner exception stack trace ---<br />   at System.Xml.Xsl.Runtime.XmlQueryContext.GetDataSource(String uriRelative, String uriBase)<br />   at &lt;xsl:template match=&quot;/&quot;&gt;(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime)<br />   at Root(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime)<br />   at Execute(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime)<br />   at System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlSequenceWriter results)<br />   at System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter writer, Boolean closeWriter)<br />   at System.Xml.Xsl.XmlILCommand.Execute(XmlReader contextDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter results)<br />   at System.Xml.Xsl.XslCompiledTransform.Transform(XmlReader input, XsltArgumentList arguments, XmlWriter results, XmlResolver documentResolver)<br />   at Findy.XsltDb.Transformer.DoTransform(XslCompiledTransform t, XmlReader xr, XsltArgumentList xslArg, StringWriter sw) in c:\inetpub\wwwroot\\App_Code\XsltDb\XsltDbUtils.cs:line 1309<br />   at Findy.XsltDb.Transformer.TransformRelease(String xml, String xsl, Helper h, String html, Boolean IsSuper) in c:\inetpub\wwwroot\\App_Code\XsltDb\XsltDbUtils.cs:line 1094<br />   at Findy.XsltDb.Transformer.JustTransform(String xsl, String xml, Boolean debug, Boolean IsSuper) in c:\inetpub\wwwroot\\App_Code\XsltDb\XsltDbUtils.cs:line 692<br />   at Findy.XsltDb.Transformer.ExecuteService(String xsl, String xml, String serviceName, Boolean IsSuper) in c:\inetpub\wwwroot\\App_Code\XsltDb\XsltDbUtils.cs:line 673<br />   at DesktopModules_XsltDb_ws.Execute() in c:\inetpub\wwwroot\\DesktopModules\XsltDb\ws.aspx.cs:line 130<br />   at DesktopModules_XsltDb_ws.Page_Load(Object sender, EventArgs e) in c:\inetpub\wwwroot\\DesktopModules\XsltDb\ws.aspx.cs:line 44


Jan 18, 2011 at 6:48 AM


When you access mdo:service from server, it is not receive authorization cookie. Therefore it will newer get access to secure service.

I've added a @secure attribute to mdo:service tag so you can setup services separately.

        <mdo:service name="some" type="text/xml" secure="yes">


  • document() function will never work with secure services
  • mdo:node-set() maybe will work if I can manually authorize request. But I don't know how at the moment.

Best practices:

  • When you provide external services you better use a separate aliased module ( It has a fixed URL (while mdo:service URL may change in future) and it never checks permissions.
  • When you plan code reusing - use separate aliased module and mdo:import or now mdo:importable block and mdo:import-local()
Jan 18, 2011 at 8:54 AM


I just installed 2.0.39, and all is back working. I set "secure" to "no", but even where I did not add this calls are working (is the default "no"?) using mdo:node-set.

I do not use an aliased module because a) I wanted to keep code in one single xsl, and b) it would not allow me to differentiate configuration for different module instances - an alias must be unique, isn't it? If I have to name the alias of all my modules it's quicker to use my approach, that relies on moduleid finally.

Within my "modules", XSLideshow and XSLider, I use services this way because they allow me to configure each module instance separately, and to load xml from any module service just specifying the corrent url params (mod and now tabid). So I can have one configuration, say "XSLider 01.00.00", which I share between dozens of modules, but each module is configured separately AND it can expose an xml-rpc service exporting its own data.

Using mdo:node-set and this approach,, I can configure an instance to request data to another instance, sharing content easily (mdo:service calling mdo:service of another module). This is what stopped working with .38, but is back ok now with .39.

For example:

<mdo:service name="GetSlides" type="text/xml" secure="no">
<xsl:template match="/">
 	<!-- url is a full url given in configuration -->
	<xsl:variable name="url">{{mdo:get-module-setting('Slides')}}</xsl:variable>
	<xsl:variable name="src" select="mdo:node-set($url)"></xsl:variable>
	<Slides src="{$url}" count="{count($src//Slide)}">
		<xsl:for-each select="$src//Slide">
			<xsl:if test=".!=''">
				<xsl:variable name="fileName" select="@filename"></xsl:variable>
				<xsl:variable name="slideContent" select="."></xsl:variable>
				<Slide filename="{$fileName}">{{$slideContent}}</Slide>

I'll try to convert this to importable templates, but still I will need to load data from another module instance. 



Jan 18, 2011 at 10:46 AM

yes, "no" is defauilt.

So as I can see your main point is to have single configuration that is capable of

  • Showing some content and providing some UI functions
  • Providing XML data outside it's page and outside current site (XML web services). URL must be fixed and relatively simple, without tonns of IDs but with unique handmade alias (maybe use url rewrite...). Services must be easily accessed from server and from browser, including user authentication and authorization.
  • Code reusing across all parts of the configuration
  • Providing code blocks to be reused in other configurations (server side API)

This requres me to spend a couple of hours designing architecture of such solution. I'll share preliminary design with you.

When I started developing XsltDb I believe that DotNetNuke Page / Module structure provides a good containment for simple specialized modules. All business functions will be provided as solutions where solution is a set of pages, modules and configurations linked to each other. I plan to create a packaging system that will support creating installation and upgrade packages for a particular solution. This is very close to Open Web Studio architecture, but I dislike it as it is not developer-oriented, I don'f feel enough freedom using it.


Jan 18, 2011 at 11:21 AM
Edited Jan 18, 2011 at 10:01 PM

Yes, exactly :)

As with friendly urls, I recently stole the Blog module approach and reused for a custom module (see, not that difficult this way (still has entryid in url).

URL shorteners could also come to help... for example this url  resolves to an mdo:service url with a lot of params...

I also looked at OWS, but didn't like its interface too. XsltDb is maybe somehow for "old style programmers", that is you have to write down code and know what you're doing instead of pressing buttons on a IDE. But:

  • it allows you to be VERY fast in producing modules
  • it uses standards (xslt) where I believe OWS does not
  • is perfect for ajax & xml integration
  • is easy: if you understand xslt, you quickly get to produce something useful (this is RAD, isn't it?)
  • is powerful: is there something we can't do with it? Yes, cofee ;-)
  • ah, yes we also have an IDE: rich client + visual studio! For real programmers, though ;)

Sure OWS has some good point, like packaging (but we'll get this also, I feel). Others? Let's evaluate what to steal! :-))


Jan 18, 2011 at 9:59 PM

Mmmm... what about Razor scripts?


Jan 19, 2011 at 10:52 AM

Razor is very good template engine. It could be used as alternative. It definitely has better ASP.NET integration capability than XSLT has.

But there is one thing that I require but razor does not provide (you can find my comment by link you've posted above). I need flexible data manipulation API without knowing metadata in advance. I want get data from DB and parse it using language expression. Not prebuild ORMs as if LINQ, not XPath strings if C#... There's no way to use built-in language semantics for data manipulation instantly.

At the beginning, my requirements were

  • Flexible, language-level data manipulation without knpwing data structure in advance.
  • Safe development model that can guarantee that user (except superuser) has no access to system, files, database.
  • Robust compilable template processor.

XSLT satisfy those requirements very good. If MS would provide XQuery - it will be brilliant...

Sometimes I think thah XSLT is a good starting point for Cross CMS development. If any CMS will provide developers with XsltDb-like module, we can easily switch between CMS, create cross-CMS modules. (Your XSlideShow is a good example here as it doesn't use much DNN stuff).

Jan 19, 2011 at 1:21 PM


I start from the bottom: I was thinking these days "wouldn't it be great if other CMS had their own XsltDb module?" I'd use Rich Client to manage modules for any CMS having an XsltDb implementation, using a single language (xsl) and xsltdb extensions (mdo:*) calls. And I'd publish modules on different platforms, without modifications. Write Once, Run Everywhere.... where did I hear this? ;-)

Not exactly WORE. It wouldn't be easy, one would need to rewrite XsltDb core to let it run on other platforms, and CMS specific integration features would probably be different on different CMS. Well we could think to have abstracts, say mdo:XUser('U.UserID') to be translated to mdo:dnn('U.UserID') for DNN and say mdo:drupal('U.UserID') for an hypothetic Drupal implemenation.... 

Standards, XQuery for example, would perfectly fit such a vision, but again implementation would need to be specific.  Or we could perhaps try with Mono? This would be probably the only way to try a porting of xsltdb core without rewriting it, am I wrong? But I actually don't know what level Mono is now.

The good point, would it be Mono or other, is that XML is behind the scenes, and XML is the same for everybody. If the core would need to be rewritten, modules would not, or would need only minor adjustments.

But would be other CMS users, say Drupal, interested? Don't the already have something similar? 


I actually believe XsltDb is a great programming environment, much more than just a module. I prefer it on Razor, Linq, OWS, pure ASP.Net. I only wish more DNN users start using it! ;-)