This project is read-only.

mdo:md5 failing?

Jan 12, 2011 at 2:29 PM

Hi Anton,

I found mdo:md5 returns a wrong md5 hash, or at least... it is wrong when used in your "Comments and rating" module when linking gravatar images (no more visibile at I don't use such function elsewhere, so I can't tell if the problem is only affecting gravatars.

Anyway, I wrote a different function to md5 encode (actually stolen from ;-)), and with this I got my gravatars back working. 


public string str2md5(string sText)
        Byte[] originalBytes;
        Byte[] encodedBytes;
        MD5 md5 = new MD5CryptoServiceProvider();
        originalBytes = System.Text.ASCIIEncoding.Default.GetBytes(sText);
        encodedBytes = md5.ComputeHash(originalBytes);

        //Convert encoded bytes back to a 'readable' string, stripping "-" chars
        return Regex.Replace(BitConverter.ToString(encodedBytes).ToLower(), "-", "");

Jan 12, 2011 at 7:48 PM

Hi, Alberto,

Thank you very much for the comment. The real problem here is encoding. I used Unicode, you are using ASCII, both are wrong :) Right one is UTF-8. Or you may have troubles with localization. I'll fix it in next XsltDb release.


Jan 12, 2011 at 9:06 PM

You don't make mistakes, if you don't try ;-)

I didn't check encoding anyway :) UTF8 works for the gravatar hash, and so does Ascii. Maybe unicode represents differently the @ char (you generate the hash on an email addess), but the question is: I saw gravatars working in the past, so what's changed in the meanwhile? Just curious, 'cause I don't think you modified md5 function recently, isnt' it?


Jan 13, 2011 at 5:57 AM

Unicode produces 2 bytes for any character, UTF8 produces 1 byte for ASCII and 2 bytes for other characters. That's why email's hash is the same for both UTF8 and ASCII.

I think I had changed algotithm when I started using hashes widely across the project (file names for image processor disk cache, live modules, keys for ASP.NET cache, etc.). It seems I broke md5 that time.

Jan 13, 2011 at 5:17 PM

Thanks Anton.

A couple of new ideas / questions! :-)

1) IActionable: wouldn't it be nice to have an mdo:actionable template with which to add module actions to DNN menus/containers?

This would allow to have custom module controls, in addition to main template (View), even if we should find a way to resolve "edit urls" (dnn urls with Mid and ctl parameters, needed when you want to load a control which is not the main view for module).  A module Edit control is the perfect sample: when I want a custom interface to configure module I do not rely on module Settings (or use that only for basic configuration), but develop custom edit controls to load when needed. This is not available with xsltdb: mdo:setup is great, but I could not yet find a way to dynamically show or hide controls there, so the "actions" could help a lot! Did you already think about something similar?

2) ws.aspx dnn integration: when inside mdo:service templates, if I'm not wrong not all functions are available. For example mdo:dnn('M.ModuleID') would not work, and must use mdo:request('mod') to get moduleid). But I'm almost sure I saw mdo:dnn('U.UserID') working., and I can absolutely get module settings via mdo:get-module-setting(). Is the former just a case, or are there limits in mdo:services integration with dnn?

3) ws.aspx security: maybe I'm wrong, but I believe there's currently no security check in mdo:services. That is there's no check that current user is logged in, and that he has edit permission on the module. You always demand editing functions to mdo:setup, manually manage permission checks within mdo:services, or else?


Jan 13, 2011 at 7:46 PM


1) I'm sure it would be great feature! But it is not required for my projects at the moment, so I'm not sure whether I am able to implement it in nearest future... But anyway I keep it in mind.


You definitely can show / hide controls with mdo:setup. Each setting has a visible attribute so you can setup control's visibility. All other controls that can affect visibility of a particular control must have auto-post-back attribute set to true. mdo:setup uses MS AJAX and rebuilds form when setting with auto-post-back="true" is changed.

Please, review last sample from here (under Complete Settings Example section). It shows a conditional settings visibility and cascade drop down lists (selecting USA or Canada adds another dropdown with state).

2) I've just fixed mdo:dnn() in services (last sources already include the fix). But I recommend you not using system url parameters inside mdo:service. I mean that url parameters that are generated my mdo:service-url() can be changed in future versions as passing IDs is not secure enough. Hacker can put inconsistent values and potentially kill the server.

3) Yes! this is a problem that I've been going to fix last couple of months. This is actually a problem of mdo:service, mdo:callable and mdo:ajax. I think I will fix it in nearest future.

Jan 13, 2011 at 11:58 PM

1) Yeah , just an idea. Your idea, actually: you write "be able to create additional controls (not only View and Settings) using XsltDb configuration." at bottom of :-)))

I was not aware of that "visible" attribute, damned me!! I got crazy to handle settings for my modules with other solutions, and it was so simple! Idiot me for not having seen it before! 

Point 2 is actually the same as 3 then - security - once passing moduleID as url parameter is no more necessary. I don't know how can ws.aspx understand what module configuration to load if you don't tell him by passing "mod" and/or "service" params, but... you do know, don't you? ;-)

Getting better and better!


Jan 14, 2011 at 11:32 AM


I have a new question about mdo:setup: is it possible to include mdo:callable sections in an mdo:setup template? I'm only getting errors if I try - js function non defined, that is the template is not available to mdo:setup (like it does not load inner callable sections). I tried putting the callable both inside and outside of mdo:setup, same result.

Then I was thinking I could import it, but need your help again. For xsl:import ( you write:

mdo:import(buttons) loads a configuration with alias 'buttons' 


This means I can only load xsl from other modules for which I specified a service alias? Wouldn't it be possible to use import to reference other templates in the same configuration?

For example imagine you want to share a template between the main template and an mdo:service in same configuration: should you put the shared template in an external configuration? 

What I mean is: is it possible to do this?



<xsl:template match="/">

MAIN Template

Call child: <xsl:call-template name="ChildTemplate"/>


<xsl:template name="ChildTemplate">

<mdo:service name="Servicename" type="text/xml">
<xsl:template match="/">

SERVICE Template
Call child: <xsl:call-template name="ChildTemplate"/>


Jan 14, 2011 at 8:21 PM

1. mdo:setup section does not allow using mdo:callable. Settings form does not use XsltDb integration features. It just allows XSLT + mdo:* extensions. Actually it is a design mistake. I could create an abstract xsltdb control and create particular controls (view, settings, ...) based on it. But I didn't.

2. You need separate configuration to be reused as a template both in main template and mdo:service / mdo:callable templates. But it is easy to implement inclusion of locally defined sections. I'll try to implement it in nearest future.