I encountered this problem after upgrading to DNN 6.2.1 and using DR

Hi izmpm,

Yes, this has been reported and is now being reviewed by the dev team. Please see Chad's comments and suggestions in this ticket:

https://datasprings.atlassian.net/browse/DR-17

Thanks!
Candace

Hi guys - Just a quick follow up here. The latest Dynamic Registration patch now has this fixed up and this was released late last week.

Thanks,

Chad

I'm recieving a new code after the patch that looks about right: Vs29ETkPbU4%3d But I'm still getting the invalid code error from the DNN login module.

The $(AutoApproveWLogin) token does seem to result in a log in, and the correct success message, but the account doesn't seem to verify.

Hi Craig - Are you using the DotNetNuke login module or Dynamic Login?

You might want to review this thread:
http://www.datasprings.com/dnn-modu...n-dnn-6-2/

Thanks,

-Chad

Thanks Chad,

Hi Craig - Thanks for submitting the details here. Everything you described seems like it should be working.

A few other quick questions:

1. What is the PortalID of this portal? The verification code comes from a combination of the portal ID and the UserID in an encrypted method. The only thing I think that could be happening is if we are URL or HTML Encoding the token and it should or shouldn't be encoded etc... From my testing this is working but maybe if I discovered that the URL or HTML encoding was causing a difference that might help.

2. If you use the standard DotNetNuke registration tool when creating users (or just going and creating them under Admin, User Accounts) does this then allow you to properly create users that send out a valid verification code?

I do know that the verification code needs to be passed from the query string (it does not surprise me that it does show the form field as my tests also do not show it appearing with the textbox anymore within the latest 6.2 release.


Thanks,

Chad

I am using Portal 0 on a one portal Site

This was the code generated for user id 24: verificationcode=icR6RECjwFU%3d

Creating a user manually does seem to result in a working validation code, these tend to look a bit different than the ones dyanmic registration is sending out: verificationcode=SYjv3SS4sLo_

Hi Craig - Interesting... Ok, this is something we might have to review further. I know that this has been working for some users, so maybe (it looks to me) like we are handling the code with maybe an HTML Encoding and maybe it needs to be URL encoded (or maybe it doesn't need to be encoded or decoded at all for HTML?). That would make more sense... maybe you could verify this if you tried to run the code with a URL or HTML DECODE to see if that code works? This would help us get a patch out quicker.


Maybe a tool like this:
http://meyerweb.com/eric/tools/dencoder/

Which I believe generates this:
icR6RECjwFU=

I am curious if you change that last character from %3d to maybe = if it works then?


Thanks,

Chad

Hi Chad,

Hi Stephane - This is something I am planning to test again tomorrow and get a patch out by the end of the day tomorrow or at least by the end of the weekend. I know we corrected this but apparently not specifically for some of the encoding.

Thanks,

Chad

Hi Chad, just checking in to see if there is any progress on this one.

Hi guys... Ahhh... I see. So basically this is working for some occasions except for special characters?

Craig / Stephane - I know that this has continued to be a problem for both of you guys (and others) and this is very high on my list to fix. I thought we had already fixed this except for this one last encoding issue of some sort that I can't seem to find. I am tempted to throw in a simple replace statement with %3d being an _ and see if that changes anything but I am not sure it will yet. I took this code (I thought) directly from the DNN code that is using the encoder... I am posting this below:

Public Function DSEncryptString(message As String, passphrase As String) As String
Dim results As Byte()
Dim utf8 = New UTF8Encoding()

'hash the passphrase using MD5 to create 128bit byte array
Dim hashProvider = New System.Security.Cryptography.MD5CryptoServiceProvider()
Dim tdesKey As Byte() = hashProvider.ComputeHash(utf8.GetBytes(passphrase))

Dim tdesAlgorithm = New System.Security.Cryptography.TripleDESCryptoServiceProvider()

With tdesAlgorithm
.Mode = System.Security.Cryptography.CipherMode.ECB
.key = tdesKey
.padding = System.Security.Cryptography.PaddingMode.PKCS7
End With

Dim dataToEncrypt As Byte() = utf8.GetBytes(message)

Try
Dim encryptor As System.Security.Cryptography.ICryptoTransform = tdesAlgorithm.CreateEncryptor()
results = encryptor.TransformFinalBlock(dataToEncrypt, 0, dataToEncrypt.Length)
Finally
' Clear the TripleDes and Hashprovider services of any sensitive information
tdesAlgorithm.Clear()
hashProvider.Clear()
End Try

'Return the encrypted string as a base64 encoded string
Return Convert.ToBase64String(results)
End Function


I simply was including this within the current build so we would not have to utilize multiple builds of the module but if I need to we will end up creating a specific new build specifically for 6.2.3.

If either of the two of you can jump on a call or go to meeting tomorrow Wednesday I would be happy to assist you with whatever I need to do so that I can get you a valid build.

Thanks,

Chad

A few other comments based on the other feedback in this thread:

Craig - Does the verification code work for you if you change it out to be _ instead of %3d? What if you change that to be %5f as Stephane had mentioned?

This is actually working for me (even before I did this) so I am not sure what specifically would cause it to work for me. I have confirmed from my installation that it is also adding the %3d to the end however this is not affecting the verification code as this is still working for me.

Thanks,

Chad

Hi guys, sorry for the late reply.

A little update on myself...and a big news for Chad !!!

This is actually working as I mismatch DNN versions during testing.

So if you do exactly as above (I tried this on two installations just to be sure) and use DNN 06.02.04 and DR 04.20.20, the verification code is working, even though special characters always seem to be sort of encoded.
FIY, you can either use the DR code as is or replace the special characters with the corresponding ascii code from DNN registration : both do work (meaning, you can either use %3d or %5f for example).

I still have the problem on my DNN 06.02.03 version but I don't really know if this comes from the DNN version or from a parameter on DNN / DR as I tried a lot of stuff on this test site.

Okay, I go buy my DR module and proceed, hoping not to bump on this "bug" again when playing around.

Stephane

I am experiencing this behavior as well.

DNN Version: 6.2.4
Dynamic Registration Version: 4.20.20

It would appear this issue has been going on for quite some time. Is there a patch available?

Okay guys, Chad, I bumped into this "bug" again and here is what I found and tested fully before writing this post.