Opening documents via a URL

Hi everyone

I am trying to find out if it is possible to open Worksite document in their native application (e.g. Word, Excel) via a hyperlink outside of Worksite Web.

The reason is that I would like to publish links to various documents on our Intranet. At present, we can do this by creating .NRL shortcuts and pointing hyperlinks to those but I'd like a more dynamic method if possible so we don't need to manually create .NRL files and put them on the web server.

The key thing is that, on clicking a hyperlink, the document opens as if I had gone through Mailsite or Worksite Web (i.e. in the correct application, checking out if permissions permit etc).

We use Worksite 8.0. Any ideas or suggestions very gratefully received!

Many thanks

Find more posts tagged with

Comments

dabird

Assuming that you have WorkSite Web installed somewhere, you can construct a fully-qualified URL directly to WSW:

http

///scripts/ViewDoc.aspx?nrtid=&command=ok

Where
is the the server name for WSW
is the virtual directory on the server
is a valid document moniker

If a user does not have access to a given document, this .aspx page will throw an access denied exception and prevent the user from downloading the file.

dabird

It looks like my first post was stripped of the < and > characters. See below for the corrected, readable version.

Assuming that you have WorkSite Web installed somewhere, you can construct a fully-qualified URL directly to WSW:

http/<server>/<virtual_directory>/scripts/ViewDoc.aspx?nrtid=<document_moniker>&command=ok

Where
<server> is the the server name for WSW
<virtual_directory> is the virtual directory on the server
<document_moniker> is a valid document moniker

If a user does not have access to a given document, this .aspx page will throw an access denied exception and prevent the user from downloading the file.

reidbryn

Our organisation doesn't have WorkSite Web installed (yet) and I wasn't aware of this solution. I ended up creating a simple PHP script to preform the same function. I've posted it below incase it helps anyone, and it should be relatively simple to port to ASP/ASP.NET

filename: index.php



<?php

/**
 * WorkSite Dynamic URL Links PHP Script 
 * tested with WorkSite 8.2 / PHP versions 4 & 5
 *
 * usage: http://path/to/webfolder/?id=<DOCUMENT_ID&gt;
 *
 * optional, specify document version:
 *
 *   http://path/to/webfolder/?id=<DOCUMENT_ID>&ver=<VERSION_NUMBER&gt;
 *
 **/

// change these constants for your environment

define ("SERVER_NAME", "PERSDM01");
define ("DATABASE_NAME","PERDM01");

// custom HTML page for instructions on how to create valid links
define ("ERROR_HTML_PAGE", "link_not_valid.html"); 

// check if document ID has been specified and check it is numeric
if (!isset($_GET['id']) || (!is_numeric($_GET['id'])))
{
  header("location: " . ERROR_HTML_PAGE);
  exit;
}

$docid = $_GET['id'];

// check if document version has been specified (version 1 is the default)

if (isset($_GET['ver']))
{
  $docversion = $_GET['ver'];
}
else
{
  $docversion = "1";
}

// output the custom headers to serve the WorkSite document

header('Content-type: application/nrl');
header('Content-Disposition: attachment; filename=' . $docid . '_' . $docversion . '.nrl');

// generate the content of the link

echo SERVER_NAME . "\n!nrtdms:0:!session:" . SERVER_NAME . 
":!database:" . DATABASE_NAME . ":!document:" . 
 $docid . "," . $docversion . ":";


?>

dabird

reidbryn,

Very cool solution, indeed. I am not familiar with Perl, but it looks like you're building a dynamic NRL file and sending that to the browser. Is this correct? If so, then I'd like to mention that this code will only work if the client machine has DeskSite or FileSite installed.

Regards,
dabird

reidbryn

That's correct, the PHP script is simply generating a dynamic .NRL file intended for WorkSite enabled machines accessing the links on our intranet.

Thanks for mentioning that. I didn't realise that the WSW .aspx script was actually serving a copy of the documents instead of the NRL link equivalent.

Very cool solution, indeed. I am not familiar with Perl, but it looks like you're building a dynamic NRL file and sending that to the browser. Is this correct? If so, then I'd like to mention that this code will only work if the client machine has DeskSite or FileSite installed.

RajanP

Hi,

I am trying to create URL for the document. In previous mail, it was suggested to create it as follows -

http

///scripts/ViewDoc.aspx?nrtid=&command=ok

I am using COM APIs to get the ObjectID which is said to be the document_moniker ID. But when i create the URL using the ObjectID, that URL cant be accessed directly. The URL which is getting created looks as follows -
"http:///WorkSite/scripts/ViewDoc.aspx?nrtid=!nrtdms:0:!session:v07ps45372k3:!database:WebDb:!document:10,1:&command=ok"

Plz confirm if i am creating the URL correctly? The description of the ObjectID i am retrieving is given as

"IManObject Object
....
ObjectID – String. Read-only. The object’s unique identifier within the iManage system, also
known as the object’s moniker. It can be a name or number, as in a document ID."

-Rajan

dabird

Your URL is correct. The URL formats for WorkSite Web are documented in the "WorkSite Web Application Toolkit" document. The document is available on the tech support site and on the WorkSite Web installation disk.

NOTE: If the current user does not have access to the document, you won't get it when you make a call to this URL.

What type of problem are you having with this?

RajanP

Hi,

I am still unable to open the document.
The errors which I am getting are
1. "There was an error opening a this file. This document can't be found"
2. "Unable to access the object"
3. "Internet explorer could not open the file specified"

I have attached the images. Plz let me know the URL to be formed to get the document Contents.

-Rajan

Migrateduser

Hi Rajan, maybe I'm wrong, but in your first screenshot you have a mistake in the url you write ...WebDb:!document:11,1:229713,5&doctmplt...

What is extrange for me is 11,1:229713,5

Are you trying to open the version 1 of document 11 or the version 5 of document number 229713?

I use this url and works ok:
http://SERVERNAME/WorkSite/scripts/viewDoc.aspx?nrtid=!nrtdms:0:!session Smiley Very Happy

MSSERVER:!database Smiley Very Happy

ATABASENAME:!document:35827,1:&ishtml=1&command=ok

Not sure if this is what you need, hope it helps
Javi

dabird

First, javi's observation about your moniker is correct. It is not formatted correctly. Second, the other errors, "url problem.zip" and "file not found.zip", indicate that you are trying to download "active content" (i.e., Word, Excel or Acrobat documents). I recently uncovered a bug report for IE that directly affects viewing active content via ViewDoc.aspx. See Internet Explorer file downloads over SSL do not work with the cache control headers. While the article title implies this is only an issue with SSL, if you look at Step 4 under IE6 SP1 instructions, you will notice that this also affects standard HTTP traffic as well. I made the recommended IE6 SP1 registry settings to my IE7 browser and all worked. If it is not possible to change browser settings in your environment, then you can also change the default HTTP caching mechanism to "public" in WSW. CAUTION! Enabling caching will leave sensitive documents on proxies as well as in the browser cache. If you're only working within an intranet, then this should not pose a problem.

To enable caching in WorkSite Web Components Server:

Open <wsw_install>/data/options.xml.
Search for "enable-caching". Change the value to "1".
Save the file. No need to restart IIS.

ezanol

Does anyone know if there is a way to prevent the user from having to log in to get the document, or is that dependent on the way the WSW is setup?

dabird

If you use trusted login, you can enable auto trusted login in Global Options | Application Settings. Assuming the user has logged into the network on his machine, he will automatically be logged in to WorkSite after clicking your URL.

In the past one member, javi, has had success manually attaching the userID and password parameters to his URL requests. The caveat here is that the information is passed in the query string in clear text. You want to make sure that your network is locked down if you implement it this way.

http://server/worksite/ViewDoc.aspx?nrtid=****&userID=jdoe&password=myPetsName

danim

We use a product called WSLink to handle this for us (http://www.mosmar.com.au/wslink/) . It allows you to use a URL to access documents or workspaces as though you'd opened them through Filesite or Desksite.

Working a treat for us, especially now we're implementing our intranet and through it will have easy access to our precedent bank.