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.
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
Sometimes the rendered display of an HTML email body is incorrect. Eg:
OC gmail is rendered correct
Mobile app gmail is rendered correct
Mobile web gmail is rendered incorrect
This problem occurred only on mobile web gmail.
HTML body has a <table> tag. In the incorrect case, this table tag is broken with part of <div> tag.
I tried several times in mobile web gmail. The first email displayed correctly
but the second email displayed incorrectly.
My question is: why this happen? How do I fix it?
It's been a while since this question was asked, but I ran across the same problem myself now in 2022.
First of course I looked for the error on our end and rebuilt html/css. However, I could not find the error, it seemed to happen completely randomly.
A completely identical email sometimes looked perfectly fine, sometimes it was rendered completely broken (this can also be seen by looking at the HTML code: clean code turned into a completely chopped up array of HTML code that was definitely not ours (especially early terminated HTML tables, heaps of "empty" snippets, etc).
Then, by chance, I noticed that this phenomenon does NOT occur if I permanently delete similar emails that are ALREADY in the trash (sic!).
I have been able to narrow down the problem even further: apparently GMail bundles messages, from the same domain and with the same subject line, even if they are in the trash (however, you do NOT see this directly in the inbox, but only when you are on the (broken) email in question and refresh by dragging down (mobile) - all of a sudden, all the trash messages are additionally visible at the top of this message).
I was able to fix the problem by always writing value into the subject line that does not match any other email. This avoids the incorrect bundling and the mails look flawless again.
Cost me a lot of nerves and half a day's work - maybe I can save this for someone with my contribution.
A previously working desktop application (until Friday of last week) was using the methods described here: http://instagram.com/developer/authentication/ to log a user in to Instagram. The application is a desktop application and it uses the IE browser component http://i.imgur.com/bCB5ZZh.png embedded in the program to show the user the Instagram login page and grab the auth token from the query string. But something has changed recently on the Instagram login page.
The easiest way to see what is happening is to watch this screen capture:
https://cloudup.com/cKQFpVcTv8E
Basically, there seems to be an error in History.js when opened in a HTML 4 browser like the IE browser component built into windows: http://i.imgur.com/HHJYidI.png
And if I load the full authorization URL ie: https://instagram.com/accounts/login/?next=%2Foauth%2Fauthorize%2F%3Fclient_id%3Dxxxxxxxxxxx%26redirect_uri%3Dhttp%3A%2F%2Fwww.xxxxx.com%26response_type%3Dtoken%26scope%3Dlikes%2Bcomments
... the browser component keeps redirecting and loading adding a "#" to the end of the query string.
I've found a few leads on SO:
History.js for HTML5 - Hack Needed to Not Break IE7
AND
history.js and header redirection
These seem to indicate that History.js needs to be modified to work with older browsers, but of course that would be something Instagram needs to do.
Again, this has been working for well over a year until late last week.
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.
Facebook and others offer little iframe snipplets that I can put in my site.
Example:
<iframe src="http://www.facebook.com/widgets/like.php?href=http://example.com"
scrolling="no" frameborder="0"
style="border:none; width:450px; height:80px"></iframe>
What I'd like to know is, if I put this code inside my side, could the code they load into my page access the DOM of my page? I see some security isssues if so.
Likewise facebook allows me to put an iframe into their site, this is how facebook applications work.
Could I then mine any data off any page that contains my iframe?
Note I used facebook as an example here, but many companies do the same thing so this quesiton is not specific to facebook in any way so I am not tagging it as such.
Also can the parent page access the DOM of the iframe?
Actually there are specific rules of inheritance for iframes. This is apart of the same-origin policy, and I highly recommend reading the entire Google Browser Sec Handbook.
I do know the parent page can access the DOM of the iframe. Recently we had a project at work where we had a site which needed to be 508 compliant. The iframe was not and although screen readers are handling iframes much better, the content within this iframe was not compliant. We loaded jquery library into our site, and then also loaded code into our site to manipulate the iframe (only after it loads) and at that point mashup the iframes content to be accessible.
To give you an idea of how we did it here is a sample of our jquery. (Used a lot of finds and replaces but you get the idea, you could do other things. )
$('iframe').load(function() {
var f = $(this).contents();
f.find('#sysverb_back').remove();
f.find('a.column_head').each(function(){
$(this).attr('title', $(this).text());
});
f.find('img[title]:not([alt])').each(function(){
$(this).attr('alt',$(this).attr('title'));
});
f.find('input').filter(function() {
return this.id.match(/sys_readonly\..+|ni\..+/);
}).each(function() {
$(this).before('<label for="'+this.id+'" style="display:none;">'+this.id+'</label>');
});
});
});
Although I do not know if you can from the iframe access the parent DOM.
I'm assuming cross-domain iFrame since presumably the risk would be lower if you controlled it yourself.
I've been trying to figure this out myself
Clickjacking/XSS is a problem if your site is included as an iframe
A compromised iFrame could display malicious content (imagine the iFrame displaying a login box instead of an ad)
An included iframe can make certain JS calls like alert and prompt which could annoy your user
An included iframe can redirect via location.href (yikes, imagine a 3p frame redirecting the customer from bankofamerica.com to bankofamerica.fake.com)
Malware inside the 3p frame (java/flash/activeX) could infect your user
Note that the html5 "sandbox" attribute can solve a lot of these problems if your browser supports it, and you can prevent your site from being included as an iFrame as well via X-FRAME-OPTIONS.