Joe Kaufman Bell Laboratories Inc No longer there

Seth,

Well, someone is still going to need to log into DocuWare to use the Platform service. And, technically speaking, each user should be logging in to view the files they need, otherwise they could do an end-run around security. Licensing should be kosher because concurrent licenses will be used even if you use the same platform username from multiple workstations, and if you are on named users it does't really matter anyway because you've paid for it.

But the permissions issue is a real one. If your Platform SDK code reveals documents that a user shouldn't have access to there is no way of knowing they are viewing a document from a file cabinet they aren't supposed to see. Logging them in with their own username via URL integration (or the Platform SDK) makes sure permissions are being honored for their specific credentials.

To put it another way, beware "system" usernames that have access to everything, as you can introduce all sorts of problems usually taken care of by roles in DocuWare.

Thanks,
Joe Kaufman

 

Seth,

Exactly right. You can download what you need and write as elaborate a client you want to view indexes and documents. It just takes work to write that client...

If you really kinda sorta want to use the DocuWare viewer, why aren't you just using URL Integration?

Thanks,
Joe Kaufman

Seth,

You would just use the API to download the file, then open it in Windows (the file extension would let Windows know what to open in). In C#, you just use Process.Start(<filename>) to open a file in its related application.

If you also want to see the indexes, you would have to build an interface for that. As you access the Document object, that gets you the indexes, and then you can download the document itself via its download link.

Here is the general Platform SDK documentation now:

https://developer.docuware.com/dotNet/66b2ed1e-2aef-452a-97cd-5014bbf0242b.html

and here is the .NET example of downloading a file:

https://developer.docuware.com/dotNet_CodeExamples/4354370d-a0ce-42d4-ba94-6dc848ed62c0.html

If you want to view a document without bringing DocuWare up in a browser yourself, you can use URL Integration.

Thanks,
Joe Kaufman

Phil,

Thanks for the explanation. Not sure I understand it (I thought things like Amazon VMs were almost entirely customizable and so could be configured like any local server, but you learn something new every day!

You might want to amend the documentation to either list all the unsupported cloud VMs explicitly, just say "no cloud VMs", or provide details about why some cloud VMs don't work (e.g. "Cloud VMs that do not support protocol <whatever> are not supported by DocuWare.")

Are VMs from Expedient and Rackspace supported, for example? What is the required IP protocol that is missing? Just curious...

Thanks,
Joe Kaufman

And why are Azure VMs singled out as not supported? Does that mean AWS VMs are supported?

A VM is a VM. We are running VM-based servers for our on-premise installation, so what is wrong with Azure VMs? Especially if DocuWare Cloud trusts Azure as its platform?

Thanks,
Joe Kaufman

Won't that leave a bunch of documents out in storage space? If you delete a file cabinet the files are still there, eating up disk space. Isn't the same true with trays/inboxes? After all, they are just file cabinets with a different internal type to them... I was always told just nuking entire entities (like file cabinets or trays) was a big no-no...

Thanks,
Joe Kaufman

If they have any sort of automated tasks running, then monitoring the licenses in use (the Application Type) might reveal some tasks using "Platform Service". I am not sure what Application Type the Desktop Tools use.

But if someone has a job automated that only runs once a week in the middle of the night, monitoring is not going to be of much use.

Thanks,
Joe Kaufman

Craig,

In that case, you could monitor the license types in use via the Connections Overview in the DW Admin tool (we are on 6.11 so still have access to that). I am not sure where to monitor connections in other versions.

In the Connections Overview, you can expand connections and see the "Application Type". For example, we have a mix of "Platform Service" and "DocuWare Client". Platform Service is the API, and DocuWare Client is the web client.

It sounds like you would like to have this sort of monitoring be more of a log that you could report on. I am not sure what facility DocuWare has for that, but hopefully someone weighs in on that sort of audit capability. There are some logs on the server, but those appear to be mostly for error logging, not a record of every single transaction.

What version of DW are we discussing, and is it on-prem or in the cloud?

Thanks,
Joe Kaufman
 

Craig,

What you appear to be asking for is a log of all calls made to the Platform SDK? And to be able to tell the difference between calls to the middleware layer that are from DocuWare's web client and those that are done via some custom scripting/coding? I am not sure DocuWare provides such a log, and it would likely be somewhat difficult to decipher anyway. Anyone accessing DocuWare from the web client could be a potential unknown to this company, too. How do they know who has access to the web site and who is logging in that way?

All functionality is secured, though, regardless of access method. By looking at Users and Roles set up in the system, a client should have a decent understanding of who can access what.

So, other than a full log of every single call that accesses DocuWare (regardless of origin), what would you want to report on?

Thanks,
Joe Kaufman

Callum,

I believe you can authenticate and call a redirect, all with one POST call.

My code does a second call (like yours) rather than grabbing data from the redirect, but if the redirect is just a GET you can do it all at once. The resource documentation on the Logon URL displays this:

/DocuWare/Platform/Account/LogOn?returnUrl={returnUrl}

So, the POST data logs you on and then the returnURL executes, and the response data is from that returnURL.

I am not sure how to do a second POST, though. For example, if you want to index a document, that requires a POST, and I am not sure how you would pass the second set of POST data along with the URL.

I know that at some point someone stated you could add authentication as a request header in any call, but for the life of me I cannot find the forum post about that (searching is SO SLOW!). Have you trued passing the same header straight to subsequent calls without authenticating the session first? I assume it returns that login page redirect when you try?

Does anyone else recall how to pass the username and password in the request header without needing to explicitly call the Logon URL and having a session keep authentication persistent?

I will post here again if I can find the thread I am thinking of...

Thanks,
Joe Kaufman