This page describes the authentication process for an Office add-in. It states that, for the dialog:
It does not share the same session storage as the task pane
This does not seem to match my experience. This is what I'm doing:
Task pane opens dialog with displayDialogAsync
User logs in with the dialog and a session cookie is set in the dialog.
Without passing any info to the parent (messageParent is not used), the task pane then has the session cookie set.
Is the documentation here have a mistake? Or is the session shared on some platforms but not on other platforms? I'm on Mac with Office 365.
That line in the documentation refers to the Window.sessionStorage property. Cookies and server-side storage can be shared between the dialog and the host page. I'll get the documentation clarified.
Related
I am facing issue while implementing Child Sessions launcher in my app. Basically as per Microsoft document when admin user launches child session then it shouldn't ask for credentials. However it does ask credentials (shows as popup to enter the credentials). If the user cancel it then we want to capture the cancel event.
We have implemented the child launcher functionality by referring to this url -
https://learn.microsoft.com/en-us/windows/win32/termserv/child-sessions
when it calls ImsRdpClient9.connect(), then it pop-ups to enter the credentials. Now if user clicks on cancel then I want to capture the event. I tried implementing https://learn.microsoft.com/en-us/windows/win32/termserv/imstscaxevents-interface but it didn't work. Is anyone out there to show an example how to implement the IMsTscAxEvents interface and listen to the various event (e.g, OnLogonError, OnAuthenticationWarningDisplayed etc) when windows show up with the logon error (on child session launcher).
Related question: Outlook Web add-in - localstorage is cleared between messages
My question here is why are cookies cleared but localStorage retained for Outlook Add-ins used on the Outlook desktop app? I would have thought that both would have worked in the same way. It seems to me that clearing cookies is a bug in the way Outlook uses the Edge webviews.
By cookies, I believe you are referring to session cookies. In other words, cookies without an expiry date. When the add-in is closed, the underlying browser is also closed, hence the session cookies are deleted. More info on cookie lifetimes here. You can compare this behavior to sessionStorage, not localStorage. So, try setting an expiry date on your cookies to preserve them beyond the add-in session.
Keep in mind that we don't preserve session cookies for the entire item session (or Outlook session). We only preserve them for the lifetime of the add-in instance.
Refer to this similar known issue for more information:
https://github.com/OfficeDev/office-js/issues/846
My add-in has multiple drop down items when you click the add-in button.
All of them will navigate you to the same log-in page.
But after log in, the app needs to know to which subsequent page the user need to be redirected to.
For example, when I click the "play" button in the drop down, after log in I will be redirected to the play.html. And "study" will be to the study.html.
If the log in page(taskpaneurl) has no such knowledge, I need to have multiple log in page tided to different subsequent pages.
The add-in platform doesn't provide an API for this, but you can do this by providing a query string in your url.
I have created an outlook add-in which has a login page and a protected page.
When the user launches the add-in, the protected page is attempted to be loaded, if the user session is not valid the user gets redirected to login page. Once logged in, until the cookie expiration, the user never needs to login again even if the task pane is closed.
This is working as expected in Outlook 15.4. But in Outlook v16.9, the behavior seems having changed.
It looks like when the task pane is closed, the cookies are being cleared out and every time the user tries to open the task pane, the login page is shown. The cookies are http-only set by the server on login.
Is there a workaround to retain the cookies on closing the add-in task pane?
We are developing an Outlook add-in which requests tokens from Active Directory for an on-behalf-of flow. Once the user has logged in to AD once, and has a login cookie from AD, we'd like to request any further tokens from AD through an iframe with the prompt=none parameter.
In order to work around protected mode, we've added the url hosting our add-in to Trusted Sites, as well as https://outlook.office.com and https://login.microsoftonline.com. When the add-in is run from Internet Explorer, the entire page runs with protected mode off since outlook.office.com is in Trusted Sites, so our iframe can access the login cookie set by AD on login.
Our problem is running the add-in from the Outlook desktop client. When the iframe loads login.microsoftonline.com, the login cookie is not sent. I suspect this is because the desktop client might be running the add-in in protected mode. If I run Outlook as administrator, the cookie is sent, and the add-in behaves like it does in the browser.
Is there any way to make Outlook run the add-in with protected mode off, short of running the client as administrator?
This issue is related with the Integrity Mechanism. Please refer to the link below for more information about Integrity Mechanism and Protected Mode.
https://msdn.microsoft.com/en-us/library/bb250462(v=vs.85).aspx#upm_ovwim
If the sites are in Trusted Sites, they run outside of Protected Mode, and the cookies are stored in the Medium Integrity Cookie Store.
Outlook Add-in is secured by an add-in runtime environment, in which an Internet Explorer control is hosted. When the UAC is enabled, the add-in runtime is running with low integrity level. The Internet Explorer control also runs with low integrity level, and it can't retrieve the cookie from the Medium Integrity Cookie Store.
Therefore, when the iframe loads the site, the login cookie is not sent.
To resolve this issue, there are three methods below.
Remove the sites from Trusted Sites in IE, and then run the add-in
from Outlook. This can store the cookies in the Low Integrity Cookie
Store.
Turn off UAC, which makes the all programs run at High Integrity
Level. However, this is not safe for IE.
Elevate the IE broker process to medium integrity level by creating
an elevation policy. Please refer to the following link for How-tos.
https://msdn.microsoft.com/en-us/library/bb250462(v=vs.85).aspx#upm_cfgpm
Note : deactivation of UAC should only be done for testing purposes, if you deactivate it (permanently) on productive computers you will create a major security hole, please do not do that