SOLVED

Bad first impression of user experience

Iron Contributor

We are starting our internal O365 promotion campaign and I wanted to leverage Stream for that.

 

I wanted, I tried but I wont. I found no way to send a video without showing a connection prompt.

 

Users don't know what Office 365 is so it is not logical to prompt them to connect to see the introduction video.

 

If I send a link to the video in an e-mail, users are welcomed by a page asking them to register or connect.

 

I tried to embed the video in a SharePoint page. I can see the page without the need to login because the SSO does it's job but, for some users, they also need to connect to Stream before the video is played. 

 

This is not what we want. 

 

The video services looks a little better but I am fighting with link details.

 

So, at least for now, we will host the Office 365 promotion video in vimeo. :(

 

Is there a workaround I didn't see? 

7 Replies

I'm sorry you are running into login issues and having a bad first impression of Stream.

 

Stream is meant to be an internal/secured way to share videos within an organization. As such each user does need to be logged in to view a video to ensure that they have view rights to see a specific video. We have a future feature for public anonymous videos where people can access without a login on the roadmap, but for now each user needs to be logged in.

 

If a user is already logged into another O365 service then when they click a link to a video it will work without a login prompt.

 

With that being said there are a few things we are looking into that hopefully will help smooth out the login flow.

  • Video link takes you to the Stream marketing page and users are confused - We are looking into redesigning that landing page so it's more clear that users need to login in to see the video link they just clicked on. We take users to this landing page today because our service allows for both licensed users and free trial signups. As such we don't know for an unlogged in user if they do have a license or not. Our goal is to fix up that landing page to make it more clear what the user should do as opposed to the primary focus being a marketing page.

 

  •  Embed, some times see login - Do you use ADFS at your organization? If so, we do have a URL parameter that you can manually insert into a Stream embed code to help "accelerate" the login flow from within embed. The parameter "domain_hint" can be set with the domain used by your ADFS server, as such it will skip the home realm detection from the login.microsoftonline.com login page and jump directly to your ADFS login page. In some cases this may allow our "auto-login" in more cases.   Here is how to set the parameter into embed manually. Add the &domain_hint=<domain of ADFS server> to the end of the embed SRC.

     

    <iframe width="640" height="360" src="https://web.microsoftstream.com/embed/video/211de721-9437-481b-bb89-3601c0fbd0c4?autoplay=false&showinfo=true&domain_hint=mydomain.com" frameborder="0" allowfullscreen ></iframe>

Thanks for the quick reply. 

 

I understand that Stream is meant for internal sharing and it is what I want to do. My issue it that users don't know they need to connect using their network credentials and not register to that new service that they don't know about.

 

For this first communication, an easier way to connect is required.

 

We do use SSO thru ADFS. I tried different recipes of smart link to bypass the login prompt but none worked.

 

I tried to add the &domainhint but it doesn't work either.

 

I will monitor Stream's updates for future uses.

 

Thanks again. 

Cool, thanks Marc!  The domain hint looks a little different than smart links (or smartlinks, including both for searchability).  I was looking for this info yesterday and came across a good write up here: Using smart links to improve the login process to Office 365 applications  I was not able to get that format to work with the embed code for a stream video.  I am not sure if that is even possible.  Any ideas on that?  Maybe it just can't work inside the src of the iframe. 

 

What you described with the domain hint allows for an automated authentication after briefly showing the sign in or sign up, which is should work ok for what I am doing and is definitely an improvement over what we had before.  This will primarily be used for videos that are embedded into on-prem SharePoint pages or Yammer.  We have a hybrid environment and there is still a lot of confusion around O365 so any reduction in auth prompts is helpful.

best response confirmed by Benoit Fournier (Iron Contributor)
Solution

Those smart links are against the login server "login.microsoftonline.com" The issue is that login.microsoftonline.com can't render inside of an iFrame (to prevent click jacking). As such we have a bunch of logic inside Stream embed to determine if we are in an iFrame then render a button that launches login.microsoftonline.com in a new page so user can log in. We added support for domain_hint (which is an option to login.mso.com) to our embed page so we can pass it through if needed to login.mso.com.

 

I bet if you did the smart links correctly with the right redirects you'd be able to make it work in cases where the user is logged in, but likely not make it work when the user does in deed need to login.

 

We have an item on our backlog to better investigate ADFS and SSO to determine if we can build a feature to help more in these cases. Right now you having to put domain_hint=server.com into your embed codes manually isn't great. Ideally we'd have a way to do this always for your if you set it up.

@Benoit Fournier - I just realized my example iFrame got cut off in my previous post. I just edited to make sure the full iframe src is shown. If you add &domain_hint=<adfs server> to the embed code it should help in some cases. As @some guy tried and worked for his ADFS setup.

 

<iframe width="640" height="360" src="https://web.microsoftstream.com/embed/video/211de721-9437-481b-bb89-3601c0fbd0c4?autoplay=false&showinfo=true&domain_hint=mydomain.com" frameborder="0" allowfullscreen ></iframe>

This is the part you have to add to the end: &domain_hint=mydomain.com

Where mydomain.com is the server where your ADFS login server lives at.

 

Here at MS our ADFS server is "Microsoft.com" so I'd add: &domain_hint=microsoft.com

 

Just wanted to double check that you have the format/info right as my post got truncated originally.

Hi Marc,

 

As I said, it's our promo video and we do not want users to login. Your hint may help when it will be embedded in a SharePoint page but what we needed now was a direct link in an e-mail.

 

Thanks for your help and I will watch the "Stream Ideas" page for updates. 

1 best response

Accepted Solutions
best response confirmed by Benoit Fournier (Iron Contributor)
Solution

Those smart links are against the login server "login.microsoftonline.com" The issue is that login.microsoftonline.com can't render inside of an iFrame (to prevent click jacking). As such we have a bunch of logic inside Stream embed to determine if we are in an iFrame then render a button that launches login.microsoftonline.com in a new page so user can log in. We added support for domain_hint (which is an option to login.mso.com) to our embed page so we can pass it through if needed to login.mso.com.

 

I bet if you did the smart links correctly with the right redirects you'd be able to make it work in cases where the user is logged in, but likely not make it work when the user does in deed need to login.

 

We have an item on our backlog to better investigate ADFS and SSO to determine if we can build a feature to help more in these cases. Right now you having to put domain_hint=server.com into your embed codes manually isn't great. Ideally we'd have a way to do this always for your if you set it up.

View solution in original post