I've created a Bot in MS teams that can authenticate the user against AAD. I've used the AuthBot code for this.
This works correctly. I have questions regarding further improving the sign-in experience. The Bot currently opens up a web browser, the user logs in and is redirect to a page with a magic number that he or she needs to copy-paste back into teams.
If I understand the Authentication section on this page correctly, then the following should be possible:
The browser window can be opened inside of Teams instead of through
the browser by specifying a validDomains attribute in the Teams
package manifest file. However, I chat with the Bot 1:1 and it
doesnt seem to use the manifest file (the Bot's image doesnt use the
one from the manifest). How do I get the login window to open inside
Teams?
There is a MS Teams javascript file. Can I use this (on the page that my Bots shows after authentication) to
redirect the user back to teams, and possibly automatically paste
the magic number into the chat with the Bot?
We missed answering this in August, apologies.
A more elegant way of doing bot authentication has been a common developer request. We are almost ready to publish samples and documentation for this solution once it's fully deployed on all client platforms. This approach removes the need for AuthBot completely and supports an integrated authentication experience, i.e. without opening a browser tab.
Currently, however, to answer your question, there is no way to have an inline authentication experience and the validDomains is not enforced (since it's just opening a browser page). The JavaScript client SDK you refer to is not used at all with bots because bots cannot currently run code on the client.
So in other words, what you are doing with AuthBot is currently the best possible way to do it.
Related
I have a Chrome extension built with MV3. It is a companion product to a mobile app that allows users to sign up / sign in with email, Google, and Apple. I have used the Firebase Authentication service to set up email sign up and Chrome Identity API to set up Google Sign in (solutions offered e.g. here & here). However, Apple Sign in (or any other 3rd party auth) seems to be completely broken in MV3 because popup/redirect OAuth operations are not yet supported in MV3. Seems like such a big miss by the Chrome Extension team!
My question
Is there a workaround solution to implement Apple Sign in for Chrome extensions using MV3?
Solutions I've tried thus far
I've spent a week now testing/trying different ideas and this is the closest I've gotten. Quick summary of solutions tested (in case it can help others save time):
Firebase Authentication service for Apple Sign in. It offers two methods that can be used, signInWithPopup and signInWithRedirect. As noted above though, popup/redirect operations aren't supported in MV3, so neither of these worked. I also tried this approach (also seen here) of storing the Firebase Auth files locally in case fetching remote scripts was the main culprit. That however didn't work either because the files still have some dynamic (remote) script imports that are called at compile time (I think) which again is prevented in MV3.
FirebaseUI library. In short, this library depends on the main Firebase library and therefore you get the same issues as the above.
Sign in with Apple JS. This implementation makes a call to fetch the Apple JS script. Again, MV3 doesn't allow for remote scripts, so it fails. As a workaround, same as with the first option above, I copied the Apple JS script and stored it locally in the extension. But it doesn't work in this case either. (I don't recall the exact reason, but the Apple auth object in the file wasn't instantiating or something).
Sign in to Apple manually. The most promising result thus far but I am stuck at how to read/extract the authorization response from Apple. I've outlined that issue here.
The only remaining workaround that I can think of is that I set up an externally hosted site using Sign in with Apple JS (option 3 above). Then when the user clicks the Apple Sign in button in my Chrome extension, I redirect them to that site, they conduct the Apple Sign in, and the auth details are then sent back to the Chrome extension. That however is both a very poor user experience and presumably has many security flaws.
Has anyone successfully implemented Apple Sign in with Chrome extension MV3 or can offer some workable solutions?? Thanks in advance.
I am trying to embed our bot in a customer's IE11 :( We have our own embed but we are facing that Cross Origin Request is not supported. I am even willing to just embed the standard Microsoft in page embed (that chat box with a blue top border) but users need to say something with that embed first before bot starts opening sentence..
So my questions are:
Are there any workarounds?
Is there any working web embed that I just can reuse and plug my directline into?
Is there a way to have this default microsoft embed startup the opening sentence automatically on loading?
I'm trying to integrate DocuSign to my website. With the DocuSign Power Form I'm kind of successful to integrate. When a button is clicked in my website user is redirected to the Docusign Power Form. But what I need to do is redirect the user back to my site once the signing is done.
Is it something I can do with the Power Form?
You can control where a user is directed after a PowerForm. It uses the values set under Preferences -> Features -> "In session landing pages". Typically these values are overridden when using the API but they do work for PowerForms.
Whether or not you should use PowerForms vs. API depends on your Use Case. For example, a very static document that you want anyone who visits your site to be able to sign could work. It's certainly a lot easier than API integration. However anything more complicated would probably be better solved through the API.
It is let reply but it can help for other guy's
Firstly you can choose direct way instead of email. but keep in mind email is more secure then direct way.
Then you can changed these landing pages from the Classic DocuSign Experience by going to Preferences, clicking Features under the Account Administration section and clicking the In-session Landing pages link under Advanced Options. You can enter your website link to redirect back to the website on each action such as completing the Power-form or declining to sign. When user submit the power-form it will redirect to your given website action.
I do not believe you can control the re-directs when you use a PowerForm. Instead, the optimized and recommended best-practice approach if you want to Embed DocuSign into your website or app is to use the DocuSign API and open the singing experience in an iFrame (or Webview if doing mobile).
Check out the DocuSign Developer Center where you can create a free developer sandbox and start using the APIs in minutes. Also make sure to check out the API Tools page under the Quick Start section where you'll find the API Walkthroughs with code samples. The bottom three explain Embedded Sending, Embedded Signing, and how to Embed the DocuSign Console itself.
https://www.docusign.com/developer-center/api-tools
Chose whichever language you need, copy the code, replace the variables at the top and run!
This is the first time I've ever seen a button like this (see right side). Clicking on that button launches Spotify. How is Spotify able to do this for their emails? Can this be done with other applications right now?
Disclaimer: I am a Spotify employee, but I haven't worked on this feature personally.
Google recently added support for markup that lets you embed interactive actions in your messages. You can see the blog post about this or the developer reference. The basic concept is that you embed some structured JSON data in your message, as in this example.
We embed markup in our notification emails that links to the Spotify Open site. For example, here's a link for Passenger — Holes: http://open.spotify.com/track/33lol6G1GUj0d3DyE1QzLw
If you have the Spotify desktop app installed, a redirect on that page to a spotify:track: URI will open the linked track in the desktop.
I would say that it is probably either a feature of Gmail or Spotify has installed some kind of browser plugin that inserts this button onto any page that it wants.
Just like torrents, browsers can associate certain header types with specific programs for example torrents use the magnet:// url which the browser associates with an installed bit torrent client.
So I would assume that this button launches a url like spotify://this-is-a-song-name-987897/ which launches the Spotify program on your computer.
I'm really confused. I want to make a Chrome Extension that can update a user's Google Calendar, what kind of program should I register under Google API?
Is it Web App? But I don't plan to have a server to host anything because Chrome Extensions are in the browser itself.
I really don't think it's a service account, but if it is, somebody enlighten me!
So that leaves installed applications?
Well, Google Extensions and Google API are very different in nature, and they don't have a special way to comunicate themselves.
Chrome Extensions are javascript code running in the browser allowed by a Chrome user, with more rights than a normal page; while Google API is accessed by server code, just as Google Apps Scripts (javascript code running in a Google server with some Google user's right).