Mike,

This has everything to do with the way DNN treats an incoming request. If unathenticated the user is redirected to the login page. When the login is successful, the user goes back to where the original url wanted to go BUT only the tabid is preserved. Argh. I didn't make this part up. I've raised this several times in the dnn forum, but I'm not sure if it made it to the todo list for them.

In short: it's a DNN issue.

Peter

Peter,

I had pretty much assumed it was more of a DNN issue than DMX. I had the same problem using the ActiveForums module. We are using it to post announcements, but had the problem when sending out links to new annoucements in mass emails. I am now testing NukeNews (www.orizonti.com) for announcements and I do not see the same problem there. Maybe that's something you could look at to see how they are getting around the issue.

With all the work done on our intranet and all that's left to do, this simple little issue seems to be a sticking point for our Execs, so I'm anxious to find some workaround or resolution.

Thanks

Mike

Peter, meant to be fixed in the upcoming release, according to gemini and the blogs on dotnetnuke.com

(Finally!!! - This has been pissing me off for ages too!)

Cheers,
Andrew

Mike, Andrew,

It's good to hear it will be fixed. I'll leave it at that as I want to avoid 'work-arounds' expecially for problems that should never have been ... (I mean I find it just not logical that DNN should strip the contents of the querystring when going through the login. What's easier than to keep the original requested url without any modification somewhere?). Is this OK with you (and your execs) Mike?

Cheers,

Peter

I'm beginning work on my migration from dnn3.1 to dnn4 so I will be ready to use this upcoming update.

Thanks

I recently upgraded my DNN site to 4.3.5 and the DMX 3.04.07.

Now when a user gets a subscription notice and they click on the link, they are redirected to the home page for the portal not the login page. Once they login they are not redirected to the file/folder they received the subscriptions notice for.

Any thoughts as to what could be wrong?

No. It works for me. It seems this part was fixed in DNN (the redirection losing the parameters).

Here is what the link that we get in the notification looks like:
http://10.25.33.91/naspor...le=425&EntryId=29180

This is what I would have expected in the notification:
http://10.25.33.91/naspor...t.aspx?EntryId=29180

This is the link if I login and go to the entry looks like:
http://10.25.33.91/naspor...t.aspx?EntryId=29180

This is the link that is created if I logout and go to the page directly:
http://10.25.33.91/naspor...px%3fEntryId%3d29180 ---It basically is redirecting me to login and once I do it brings me to the correct location.

Is the link that I am getting in the correct format to get redirect to the login page and then back to the correct page requested?

Exactly. The new links should now work with DNN in redirecting to the correct page. The last issue to be resolved there was with subportals.

Peter,
why doesn't it work with subportals ?

When will it be fixed ?

The issue is this:
Lets say you have an installation on your HD under \webroot\mydnn of DNN. You access it through some external url like 'intranet.acme.com'. The Default page loaded is \webroot\mydnn\Default.aspx. You have DMX and you wish to create a direct url to content. The direct link contains at least the tabid, moduleid, and the entryid to display. In the old days: if the module was hidden from view for unauthenticated users, you be redirected to the login page and the tabid/moduleid/entryid would be lost. Nowadays DNN preserves the parameters so that you get to the right content after being challenged for a login. So far so good.
Now you have a subportal called 'testsub'. You can access it through intranet.acme.com/testsub. The page loaded is \webroot\mydnn\testsub\Default.aspx. This page basically redirects to \webroot\mydnn\Default.aspx with a parameter that the sub portal testsub is being requested. And now comes the painful part: any other parameters that were supplied to get to the portal content were lost. So in our case the entryid/tabid/moduleid/etc. This means that linking into subportal content is actually not possible unless the core team fixes this. You're welcome to bring this to their attention as well of course.
Peter

Hi Guys,

Sorry to jump in here, but I may have a work around for Holger.

When you create the subportal, in the provided example, 'testsub' (accessed via intranet.acme.com/testsub), DNN will create the testsub sub directory (e.g. \webroot\mydnn\testsub) and create a new Default.aspx there.  This page's only goal is to do the direct back to the \webroot\mydnn\Default.aspx page.

You could try modifying the \webroot\mydnn\testsub\Default.aspx adding the additional parameters.

E.g. Update the following line (35)

FROM:
DomainName = ServerPath & "Default.aspx?alias=" & DomainName

TO:
DomainName = ServerPath & "Default.aspx?alias=" & DomainName & Me.Page.Request.Url.Query.Replace("?", "&")

I have not tried this so I'm not 100% sure it will work.  The only other draw back is that you will need to make the change to every sub portals Default.aspx manually.

I hope that helps.

Michael

Thanks Mike. So far my testing is showing that your suggestion works.

the dotnetnuke.com forum indicates that the problem persists and someone has posted some code to fix the problem, thing is I don't know how to implement the code

 

http://www.dotnetnuke.com...e/posts/Default.aspx

To further elaborate on Tiphanie Combre's mail:

Here is what the link that we get in the notification looks like:
http://10.25.33.91/naspor...25&EntryId=29180

 

When clicking this link in the notification e-mail, the portal responds:

    1.You do not have access to this item.
    2. No auto redirect to login occur
    3. The user then click Login and do a regular login
    4. The user is then directed to the Document Exchange root and not to the document in question.

Is it anyway to improve this behaviour(the same thing is happening even if the user is logged in, in advance of clicking the notification link in the e-mail.)

 

Best regards,

SwanB