We have a page on our new DNN site which uses the (I think standard) links module, and we have links which open reports on the secure server.

My problem is that the URL for the link shows up on the top of the page, and we don't want our users to bookmark these links.  How can I mask the link so that it does not show the actual or full path?

J

"Masking" the URL (simply hiding or not displaying it) is not an effective security measure as you have no control over the browser/tools an end-user may employ to view data about their session/location.  Rather, your DNN instance should employ a "report viewer" module that handles the passing of security credentials to the secure server and then displays the result (a report) within the module itself, never revealing to the client (the user's web browser) where the secure server is or even that there IS a separate report server.

What is your "secure server" for reports?  MS Reporting Services?


If you're using MS Reporting Services then you have several options for securely displaying reports within a module:

Option #1:  Roll your own module that handles security credentials as detailed here: 
   http://www.adefwebserver.com/DotNetNukeHELP/ReportingServices/Default.htm

 
Option #2:  Use the REPORT module with the add-on "Reporting Services" visualizer.  See video of SoCal DNNUG presentation from 1/14/2009 (105 minutes) and files here:   http://www.socaldug.org/

   Video:  http://www.socaldug.org/Portals/0/DNN_Jan_14_2009_Video.wmv
   Files:  http://www.socaldug.org/portals/0/DNN_Jan_14_Files.zip

Option #3:  Take the easy route and purchase a ready-to-run "report viewer" module:

  SRS 4.1 ($90):
     http://www.snowcovered.com/Snowcovered2/Default.aspx?tabid=242&PackageID=12494
   
  ReportXP 2008 ($60):
     http://www.snowcovered.com/Snowcovered2/Default.aspx?tabid=242&PackageID=12251
 
  SQL Reporter 1.2 ($20):
     http://www.snowcovered.com/Snowcovered2/Default.aspx?tabid=242&PackageID=9485

 
Unless you're big on writing your own modules and/or getting involved with module extensions and configurations, option #3 is probably the best bet (as well as the cheapest considering the time saved over implementing options #1 or #2). 

-mamlin