[Edocs-development] Re: [eDocs] MSO Integration: Use Cases U9 and U15.

[Sergio R. <sra...@ti...>]

Guys,

Derek sends me an interensting email to discuss some points. I like that
everybody
Ashwini, Dobb and Razi gives their opinions about that.

>
> USER AUTHENTICATION MECHANISM: SESSION COOKIE?
>
> Presumably a user should log on.  But then what.  What if the user
> sits there for hours and does nothing?  How will the MSO VBA add-in
> communicate the user's identity with the eDocs server (the "web
> services" provider that the add-in will communicate with using SOAP)?
>
> Well, I could pass id AND password over-and-over (I've left open
> how we want to encrypt the password, for now).
>
> I figured, one of the connection points on the eDocs server web service
> could be logIn( string userName, string passWordSHA1) [or again,
> however password will be encrypted -- maybe we install a digital
> certificate on the user's workstation and they pass that back and
> forth.. however we decide to design it later].
>
> With a login( uid, pwd), then rather than login before each operation,
> perhaps the eDocs server could give the MSO VBA add-in a "session
> cookie."
>
> The eDocs server would remember the cookie correlates to my user.
>
> Then, subsequent operations from this user would carry with them the
> session cookie identifying the user.  As long as this cookie is up-to-date
> (not old, based on some presumably Administrator-set cookie expiration
> property on the server) and known, there would be no need to make another
> login( uid, pwd) call.
>
> So, anyway, the two Use Cases I did were based on this sort of arrangement
> for how eDocs Server and the MSO VBA add-in would agree to authenticating
> the user.
>

For me all the following are a nice to have:

1) User identifies himself using username and password or (better) digital
certificate
(this could be a feature of a further release. The http connection with the
eDocs server web service provider needs to be normal or SSL encrypted.

2) A nice to have additional feature could be have digitally Signed SOAP
messages that goes back and forth
with the server. This could be useful if the user want a further level of
security (Impressions??).

3) After the authentication has been successfully executed necessarly a user
needs to have
a "session cookie" that will be shared between all the applications that
possibly
needs to access eDocs server. We necessarly need to give the possibility to
set a timeout after
 which the cookie wont be valid and the user needs to reauthenticate himself
the first time
he will try to access again the server.

4) What if a user calls for an authentication to the eDocs server and then
sits for hours
doing nothing? I would like to give an "availability timeframe window" where
he can authenticate himself. If the user tries to authenticate outside that
timeframe
the system must give an error message and the process must be reinitiated (I
think
Derek this was your first question)

>
> NAVIGATING THE REPOSITORY FOLDERS REMOTELY
>
> The user could do open( cookie, folderPath, documentName), for example.
>
> The other thing was how to populate the "File Open" dialog that lists the
> Folders and Documents available on the Repository(ies).  So again, I
figure
> there'd be a connection point on the eDocs server to facilitate getting
the
> directory of each Folder.  So it would be like,
>
> getDirectory( cookie, topFolderPath, filterDocumentsByType), for example.
>
> That would be a bit-chatty. :-(  By the same standard, since there could
be
> thousands of documents under management, I wouldn't want the WHOLE
> catalog of documents stored.
>
> A compromise would be to ask for all documents/folders in this folder, and
> then all documents/folders one-level down.

Agreed

>
> Then, if the user goes TWO levels down the folder hierarchy, well, then
make
> another call ...
>
> Anyway, so there's this back-and-forth when the user is navigating through
> the File Open or Check Out dialog boxes, browsing.

I think you're right but I don't think we can't  find anything different.

>
> ONE OFFICE APPLICATION ISN'T ANOTHER FOR LOGGING IN
>
> If the user logs in from Microsoft Word, and then goes to Microsoft Excel,
> the user will not be logged in from there.  In fact, if he does, he'll
have to
> get a separate session cookie from the eDocs server.

We need to find a way to share the session cookie

> This doesn't sound too unexpected (we need one VBA add-in per Office
> application, and they don't generally talk to one another ...)
>
> One possible design would use a local COM server, a process existing
> outside of all Office applications that is started before starting the
first
> Office application.  It could serve as an intermediary for the state (the
> login session cookie) and the Add-ins could consult it to determine
> whether to let the user log in, or conduct other eDocs operations.  It
> may be possible for an Add-in to start it, although I can't guarantee
> even with reference counting that it might not be orphaned (if an
> Office application instance crashes, there would be no way for it's
> Add-in to Release the reference in the local COM server).

We can implement a sort of in-memory link between the add-ins and a
local server. When the apps starts up it inform the server about its
presence.
The local server insert a reference in a list of applications that are
running. That link will be removed when an application closes because
the add.ins will inform the local server about that. During normal
operations the local server will check for application presence looking at
the list of running application. If an application crashes the local server
will
not have any answer back and so it will remove the app from the list.

Any thought about that from everybody??

Regards

Sergio