CODEWITHSUNDEEP
javascriptsession-cookiesoffice-js
Mog0
Mog0

Reputation: 2129

Office JS ui.displayDialogAsync loses session cookies when closed

I'm trying to build a Word add-on using the Office JS API that talks to an external web service (under my control).

I'm opening a dialog with ui.displayDialogAsync, which immediately redirects to the external server's login page (the redirect is to get around the same domain limitation).

When the user enters their login details correctly the server sends a session cookie back.

Unfortunately, in older versions of Word 2016, when the dialog is closed in Word, all session cookies are forgotten and any further requests sent to the web service from the add-on are rejected as no cookie is sent.

The problem exhibits itself in Volume licensed versions of Word 2016, but not in Office 365 versions of Word 2016, which seem to have a higher version / build number.

If I use Fiddler to view the requests / responses, I can see that the requests made from inside the dialog come from a different process ID to those made after the dialog closes.

I can't use persistent cookies for a combination of security reasons (once user closes the browser, the session needs to be terminated) and also persistent cookies seem to be shared with IE and we need to have independent sessions in IE and Word at the same time (some important state is stored in the cookie).

Has anyone else encountered this / know how to get around it.

Upvotes: 0

Views: 920

Answers (2)

Mikalai Sokarau
Mikalai Sokarau

Reputation: 1

I see that starting with version 2107 build 14228.20250, dialogs opened from the Word desktop started sharing cookies with the sidebar automatically. I also checked it with Fiddler, now Word uses the same OS process to open a new dialog.

Upvotes: 0

Sjoerd Teunisse
Sjoerd Teunisse

Reputation: 41

The dialogs run in separate processes thats correct.

See for info: https://learn.microsoft.com/en-us/office/dev/add-ins/develop/dialog-api-in-office-add-ins

Note that: "Store the information somewhere that is accessible to both the host window and dialog box. The two windows do not share a common session storage, but if they have the same domain (including port number, if any), they share a common local storage."

So option one: is to use local storage if you meet the requirements.

Option two: you could use a function called Office.context.ui.messageParent() to message your host (TaskPane) with a sessionId it needs to store and store it from the TaskPane

Upvotes: 3

Related Questions