We use DocuSign embedded sending feature. Basically we create envelope through API and then display to a sender an iFrame window with envelope sending view where he can do final configuration and click the send button.
Google is introducing a change from Chrome 80 that is well described
here:
https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
and here: https://www.chromestatus.com/feature/5633521622188032
Long story short: Any cookie that requests SameSite=None but is not marked Secure will be rejected by Chrome starting from version 80.
Currently we can see that DocuSign is not ready for this change. We see warnings in console about same site cookie.
When we change Chrome experimental flags: "SameSiteby default cookies" and "Cookies without SameSite must be secure" to enabled (as it will be set in Chrome 80) the iFrame stops working completely.
The questions are:
Is DocuSign aware of the change introducing in Google Chrom v 80?
Is DocuSign planning to develope neccessary changes so the iFrame will be working?
When those changes will be delivered?
Thanks Rafal, we were not aware of this issue. We are going to take a look at Chrome 80 (which is releasing in a month) and see what the issues are and get back to you with a resolution soon.
Have you considered redirecting to DocuSign instead of using an iFrame? Redirecting is recommended.
I just turned on the Chrome experiments mentioned in the article you referenced and the Signing Ceremony worked fine when I redirected to it.
Related
I have an extension that has been working for almost 2 years now with out issue. I havent made any changes in about a year, but recently i started seeing some change in behavior.
I use the Webrequest APi to intercept navigations. During the callback for some websites i need to do some security evaluations async. When this happens I redirect to a local resource (html) as an interstatial page that tells the user what I am doing. Once complete based off the evaualtion the page is redirected where it should be. This is ussually very fast and has worked great for the last 2 years. Since the latest version of chrome things dont seem to work anymore for all cases.
If i intercept an address bar navigation. everything works as expected. The interstatial pops and everythings great. However. If i click on the same website as a link on a webpage. I get the "Blocked by Extension page". (what you would get if the nav was cancelled). I also noticed that my interstatial is showing up in the web history and if i click on it from my history page everything works.
It seems as if a bug might have been introduced by google?
Just wondering if anyone has seen this.
Thanks
I am trying to run Microsoft's sample code for implementing Azure AD B2C authentication.
The codebase can be found here:
https://github.com/Azure-Samples/active-directory-b2c-javascript-msal-singlepageapp/blob/master/index.html
I modified the code so as shown in the following gist. The main change is that instead of using the Msal.UserAgentApplication object's loginPopup() method, I am using loginRedirect() (for the better user experience)
https://gist.github.com/ttchuah/6718e268a235a3206968b36d748fd369
Here is what happens when I run the code.
I see the index.html page as expected.
I click the login button, get redirected to the Microsoft login page, where I can see the option to do a social login via Google.
I log in through Google and get redirected back to my index.html page.
At this point, the "authCallback()" function fires.
In Chrome, I get the following console error. Any ideas why?
Refused to display 'https://accounts.google.com/o/oauth2/auth?client_id=903295266285-78au30g3bsmt8q1phvfqqu65c58kp35i.apps.googleusercontent.com&redirect_uri=https%3a%2f%2flogin.microsoftonline.com%2fte%2fdv0dop000devaad000.onmicrosoft.com%2foauth2%2fauthresp&response_type=code&scope=email+profile&state=StateProperties%3deyJTSUQiOiJ4LW1zLWNwaW0tcmM6OGM1YTQwNDQtNGYyYi00ZTJmLTgyMmUtYjU2ZjRkMWU4ZWU2IiwiVElEIjoiMDBmZjUzOTctNjYxZC00NDY4LWFlODktNzlkOThlMmEwMzI0In0' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
The same error does not happen in FireFox or Safari. For those browsers, I am able to get an auth token back without issue.
The X-Frame-Options header is a security measurement against clickjacking, the thing is, not all browsers have an implementation that takes that header into consideration when processing a returned response (see X-Frame-Options on MDN).
Long story short, Chrome will block any response processing that doesn't have a matching allow-from value in the X-Frame-Options header from rendering in a frame, iframe or object element.
Hope it helps!
It does not help with B2C, but Okta, Auth0, and OneLogin have iframe-options set out of box, as well as same-site for cookies ...
Today we noticed new undesirable behavior from our DocuSign implementation. We are using the embedded signing approach.
Server-side when the form is loading we generate the recipient view URL. This part works fine.
Then we load this URL in an iframe on the form. The iframe only takes up a portion of the form.
Previously this was working fine, but as of today we noticed some errors. The signing ceremony still loads, but we can see errors in the console in Developer Tools. They seem to be coming from inside the iframe. When we remove the iframe the errors go away.
The console in Developer Tools, shows that a 400 (Bad Request) is being received from https://demo.docusign.net/Signing/monitoring?insession=1&ti=4c6f3176cf8841b7885f76a4b5261744 (picture below). This is not a URL that we are calling, so it must be called from within the iframe.
The signing ceremony still works from a user perspective, but this error seems to be halting client-side scripts on the rest of the page. When we remove the iframe, everything else works fine.
Any help would be appreciated. Thank you!
Embedding the signing ceremony inside an iframe is not recommended.
There are multiple techniques available for maintaining your application's state while the signing ceremony is proceeding. Why do you feel the need for an iFrame?
That said, please provide the envelope_id that had the problem and I'll submit an internal bug report.
Note, the initial url your app receives is not the final url for the signing ceremony. As part of the process, the response to the initial url is a redirect to another. That's been the case for a long time.
We finally got this working.
We changed this markup:
<iframe src="{SigningCeremonyUrl}" />
To this markup:
<iframe allow="geolocation" src="{SigningCeremonyUrl}"></iframe>
As you can see the only differences are:
Added allow="geolocation" (didn't fix the problem by itself)
Removed self-terminating <iframe /> tag and used opening and closing tags
(resolved the issue)
Notable discoveries:
The bug presented itself on 11/10/2017. It was demoed working at 8:00 or 9:00am EST, and then stopped working by the end of the day (3/4/5ish), without any changes being made on our end.
When we removed the iframe containing the signing ceremony URL, the rest of the page worked fine. Adding it back recreated the issue.
When changing the URL of the iframe to Google, the rest of the page worked fine. Changing it back recreated the issue.
When running the signing ceremony URL in the whole window (without the iframe), and with Developer Tools open, it did not throw any JavaScript errors.
When running in the iframe, and with Developer tools open, the only error we saw was the one posted in the question above.
When running in the iframe, with self-terminating html tag, we ran the following test, and only received 1 alert:
<script type="text/javascript">alert(0);</script>
<iframe ... />
<script type="text/javascript">alert(1);</script>
When running in the iframe, and with Developer Tools open, it was as if the our JavaScript wasn't even there. No scripts ran once the iframe loaded.
This has been driving me nuts all day:
I have an iOS app with a custom URL scheme defined, and am trying to share a link on FB which points to a page that has this scheme in its applink meta tags, so that tapping it should fire up my app.
Every little piece of it is working just fine. I can enter my URL scheme in safari on the phone and the browser launches my app. I have tested my webpage with the FB debug tool and there are no errors or warnings - it correctly identifies all the meta tags.
If I share the link using FB on the phone or on my laptop, all works fine.
HOWEVER, if I share the exact same link using FBSDKShareDialog, it does not work. It just opens the web page with the meta tags as if it was any regular web page.
Anyone has any idea why these two ways of sharing would be different? They look exactly the same otherwise.
If anyone else runs into this problem, here's the reply from FB:
When you share with mode automatic, the app does a fast app switch over to the FB app to show the native share dialog
The post is cached locally on the device, and it does not know about app links (since only Facebook server side knows about it)
When the user opens the FB, the user sees their cached story (with no app links behavior),
This doesn't manifest with the Web mode since the Facebook app needs
to pull from the server to get the post, in which case it has all the
app links info.
This is unlikely something that we'll fix. However, after a while, the
cache will expire, and Facebook app will re-pull the posts from the
servers, in which case the app link data will be available.
In order to test this, you can share the post on one device, and then
try clicking on the post from another device. The app links should
work at that point.
Which is kind of a lame response IMO - they parse the target page to build the preview, how hard would it be to remember the applink and use it?
There could be two possible issues:
Either the one told by #NJ, i.e. you are just trying to open the link in Facebook app, using the same device from which you posted the link.'
Solution - either open link in other device or cose and re-open your facebook app and do multiple refresh
Or You have some error in your meta tags. There is one important thing though, that Facebook never mentions, i.e. they cache the URL you provide.
So any one used the web link with meta tags the first time in Facebook, Whole meta tags will be cached, and you updated meta tags won't be parsed by facebook.
Solution
To get over with the issue, use below link
Facebook debug tool
Input your meta data included web page URL and
-click on show existing scrape information to find any error
Click on Fetch new scrape information for refreshing your URL on facebook. it will clear the cache for that URL in facebook server.
I have a great working chrome extension now.
It basically loops over a list of HTML of a web auction site, if a user has not paid for to have the image shown in the main list. A default image is shown.
My plugin use a jQuery Ajax request to load the auction page and find the main image to display as a thumbnail for any missing images. WORKS GREAT.
The plugin finds the correct image url and update the HTML Dom to the new image and sets a new width.
The issue is, that the auction site tracks all pages views and saves it to a "recently viewed" section of the site "users can see any auctions they have clicked on"
ISSUE
- My plugin uses ajax and the cookies are sent via the jQuery ajax request. I am pretty sure I cannot modify the cookies in this request so the auction site tracks the request and for any listing that has a missing image this listing is now shown in my "recently viewed" even though I have not actually navigated to it.
Can I remove cookies for ajax request (I dont think I can)
Can chrome remove the cookie (only for the ajax requests)
Could I get chrome to make the request (eg curl, with no cookie?)
Just for the curious.
Here is a page with missing images on this auction site
http://www.trademe.co.nz/Browse/SearchResults.aspx?searchType=all&searchString=toaster&type=Search&generalSearch_keypresses=9&generalSearch_suggested=0
Thanks for any input, John.
You can use the webRequest API to intercept and modify requests (including blanking headers). It cannot be used to modify requests which are created within the context of a Chrome extension though. If you want to use this API for cookie-blanking purposes, you have to load the page in a non-extension context. Either by creating a new tab, or use an off-screen tab (using the experimental offscreenTabs API.
Another option is to use the chrome.cookie API, and bind a onChanged event. Then, you can intercept cookie modifications, and revert the changes using chrome.cookies.set.
The last option is to create a new window+tab in Incognito mode. This method is not reliable, and should not be used:
The user can disallow access to the Incognito mode
The user could have navigated to the page in incognito mode, causing cookie fields to be populated.
It's disruptive: A new window is created.
Presumably this AJAX interaction is being run from a content script? Could you run it from the background page instead and pass the data to the content script? I belive the background page operates in a different context and shouldn't send the normal cookies.