So, I have links from an Excel spreadsheet into a dnn site (4.9.3).  The links contain extra query string variables for a custom module, but the custom module doens't do any url rewriting and this issue can be reproduced on a page with just a Text/HTML module, or even no module.  This also happens whether Friendly URLs are turned on or off as well.

The issue is, if the page is protected by a security role for viewing (registered users, for example), the initial click of the link from the spreadsheet will cause DNN to display the login page, along with the url redirect (the original url, with query string variables in tact) and once logged in, will redirect to the appropriate page with the original url in tact (all query string variables) and as expected.

However, any subsequent clicks on any links in the spreadsheet, which open a new tab (ie 7), will have any additional query string variables stripped from the url.  The original user is still logged in because the tab recognizes the earlier session and login, but the URL is no longer in tact.  On the other hand, if the target page has view permissions for All Users, the query string variables stay in tact for all requests.  These scenarios are easily recreated by setting up two separate pages, one with view perms for registered users and one with view for all users.  Then, open Excel and create links to each page and add some random query string variables. 

The problem this causes is that you cannot view protect a page and access it from a non-DNN link without logging in everytime, or actually, logging out, then logging back in every time.  Any insight as to why this is happening and how it may be address would be greatly appreciated!

Hi Robert,
Thanks, but you're missing the point...  I'm not using any module to access any documents and I'm not using any custom code whatsoever to replicate the problem.  Here is how this can be replicated:

• create a page visible to All users
• create another page visible to Registered Users
• Open Excel and type in the URL to the page that is visible to All Users, and add some query stuff to it (like default.aspx?id=12345&abc=123)
• make sure you have explicitly logged out of the portal and close all browsers
• click on the link in the Excel sheet to the page visible to All Users with the extra query string stuff.  You will be taken to the page correctly and the original URL will be in tact (the query string stuff is still there).  This what one would expect...  this is what we WANT to happen in the next scenario, but it doesn't...
• make sure you're still logged out and close all your browsers again
• in Excel, type the URL to the page that is visible only to Registered Users and add some query string stuff just like you did above
• click on the URL in Excel and you will be taken to your portal and presented with a login screen.  The url in the address bar will look similar to this:
  Default.aspx?tabid=58&ctl=Login&returnurl=%2fdnn%2fCallCe...
  You should notice that the returnurl query string variable has your original url, complete with the query string variables you added
• When you login, you are redirected back to the original url from the Excel sheet, complete with the query string variables you added. This is good and is what we expected to happen.
• Now, without logging out and without closing your browser (I'm using ie7 and have tried with FF, both work the same), click on the url in the Excel sheet again.  This should open another tab in the same browser.  However, the url will NOT contain any of the query string variables you added.  This will happen on every click from the Excel document into the security role protected page while you are logged in.  The same behavior happens with Friendly URLs turned on or off (in which case, only the tabid variable is left in tact.).  This is the behavior that is unexpected and in my mind not good because, in order to protect a page that could be accessed from elsewhere using a security role, you have to explicitly login (or log out, then login again) to maintain the query string variables.

Hope that makes sense and that someone has a reason for this behavior or a solution to it...

It's also not happening for me, perhaps it's something particular to your setup/site. I recommend you download fiddler (http://www.fiddler2.com/fiddler2/). This will allow you to see the requests and see if theres a hidden redirect happening or if the request string is being truncated before it makes it to DNN.

Cathal