I have an iframe with an embedded DocuSign. When I try to navigate to this page using cypress tests, the document won't open. I couldn't find much information on google. Is it a drawback in cypress that won't support docusign inside iframe?
Cypress has hard time working with iFrames; however, there are ways around it in most situations, which you can read about here.
The problem with DocuSign, from what I remember, is the document originates from a different domain than your test application. If that's the case, Cypress isn't able to test elements within a different domain, as it is bound to a single origin.
If that is the case, I would see about using Cypress to interact with the DocuSign API directly and testing its integration with your application that way, if possible.
Related
I work in a company where we have many different applications. To reduce code repetition and keep the experience for the users the same across applications we created a component library which is used by all applications.
Now we want to allow the users to switch between applications. Something similar like Google does:
Screenshot of Google Application Drawer
An additional requirement for our "Application Switcher" would be that it "updates" itself. Meaning if we change how this "Application Switcher" looks we don't want all applications which use this Switcher to create a new deployment and be newly deployed.
So currently we use the same header (from our component library) in all our applications. So, my idea was just to simply add a script tag to all the index.html pages of all the applications which should support this "Application Switcher". The Script would parse the DOM, find the header and inject a component for this application switcher. I wanted to host the actual script from a CDN like server and the script tag in the index.html just references this URL. This way we could change this script however we want, and all the applications will always get the latest version.
Now I did a small proof of concept in our environments and solved all the CORS issues but since we were fetching from an authenticated context and the script was also in an authenticated context I always got a 401.
Additionally, we have the requirement, that this "Application Switcher" shows different applications to different users i.e. depending on which apps a user is allowed to access. So, the script itself will also do calls to an "Application Switcher" backend providing it user-specific information.
Now this makes me think that my initial idea of just putting a script tag and fetching from a CDN was too simplistic. Now I'm thinking if it would be better to implement a rest endpoint in all applications to fetch this script. This way I don't have the problems of fetching a resource from an authenticated context from the user's browser and instead can handle all of this in the backend.
So long story short; I feel like a complete noob who just hacks around to get things working (or actually not working) and was wondering if any of the smart internet people out there (who might actually already have experience with this) could give me a hint what would be a clean way to implement this?
My company has one program that creates a pdf from a template pdf and another that sends that pdf through DocuSign. It has worked all along for I don't know how long (it predates me working here). But lately when I try to send the pdf through DocuSign, I get a PDF Validation Error. This just started happening in the last week or two. I can open the file in Adobe Acrobat Reader and print it with CutePDF Writer and then it works fine. Just don't know why DocuSign all of a sudden doesn't like the pdf's. Any ideas would be greatly appreciated.
You have a potential regression bug.
Confirming a regression bug
Isolate: does the PDF work via the DocuSign web app? If it does then the problem is with your API integration and you'll need to determine the problem there.
If you have an older pdf that was used to successfully create an envelope, test it to see if it still works (via the DocuSign web app). If it does then your PDF software changed. Not a regression bug.
The best test is that a PDF that previously worked no longer does.
If you've confirmed a regression bug
Please contact DocuSign developer support
You'll either give them the PDF to analyze or, if it contains private data, you should create a test pdf that also doesn't work via the DocuSign we app.
Catching regression issues sooner
DocuSign strongly recommends that all software developers build automated tests for their software to exercise the DocuSign integration/APIs.
Then set up the tests to automatically run daily against the test platform (demo.docusign.net). Accounts on that system are no charge.
If your automated test detects a regression problem then you should immediately contact DocuSign Developer Support.
Regression bugs are rare
DocuSign uses thousands of automated regression tests to ensure that new releases don't cause regression problems. But issues do slip through.
By testing against the test platform, you have the opportunity to discover an issue (and alert DocuSign) a week or more before the scheduled production release.
Thank you all for your suggestions. They were very good suggestions. However, it turned out that it was my pdf template that was being used to create the pdf. It had Adobe signature fields in it and it appears that Docusign has decided they don't like Adobe signature fields. I removed those fields from the pdf form and it worked fine.
I'm currently trying to place the docusign console onto my website. My current method is using an iFrame but I'm wondering if that is secure and the optimal way of doing it. I was also wondering if the docusignAPI has a solution to that implemented already because I couldn't find one after playing around on the website with various code sources.
Preferably, users would be able to go to some part of the website, view the contract or document they need to sign on the website without having the leave the website. This includes viewing the document on the website as well such as using an iFrame allows.
Using iframes to host DocuSign embedded signing is not a good idea for a few reasons.
Typically to have a good experience it is recommended to use a large window.
Security Concerns. The users of your app wouldn't be able to see the DocuSign URL as well as the green check to know they're using a secure website which should make them feel more confident about using your integration.
Noticed a Performance Test feature on Azure Web Apps.
Appreciate if I can get clarification on below:
Is it possible to test multiple pages?
Possible to specify which pages to test?
Possible to test the login state of the user so that performance test including backend API call etc?
Each test only test on a single URL.
Can specify which URL to test.
Only HTTP GET requests can be made from tests. If API calls depend on tokens in the URL only, they can be tested by this feature.
Yes, you can create a WebTest with Visual Studio to test multiple pages and have specific validations. https://msdn.microsoft.com/en-us/library/ms182536(v=vs.90).aspx. Once created, you can upload as the test
Yes, see #1
Yes, the WebTest will record all steps and reproduce them, cookies and all.
I would like to implement the following use case as a Chrome extension:
user visits gmail
exension checks current email body for a keyword
if a keyword is present, a gmail filter is added and saved (adding label, archiving, the details are not important here)
The first part sounds easier: there is gmail API to work with and even a gmail.js project that should make it easier.
Adding filter seems to be much harder. There is email settings API doing precisely what I want but I am fairly sure it is usable only by business accounts (custom email domains, won't work for gmail.com). I want the solution to be more universal.
One thing I thought of was to use browser automation - upon seeing the trigger keyword, the script automatically clicks 'Add filter' link, waits for AJAX, sets filter parameters and confirms.
An example of simulated user activity is in this answer
This could happen either on gmail page behind the popup ('Please wait, adjusting filters') or in background tab to keep it from interfering with user's flow. This seems like ugly workaround for me, though.
Is there a more straightforward or simply better approach that I'm missing?
After more experimentation and reviving an older github project I found out that setting the filter for a logged in user can be achieved simply by issuing a specific POST message to gmail from the current session.
I don't fully understand the parameters used in this request (if anyone has better information, please share), but I found a sample code which was greatly helpful.
Second issue, widely discussed in gmail.js community, is that Gmail security policies will prevent you from injecting your own scripts. This is bypassed by method shown in this boilerplate project
I compiled these solutions to solve my particular use case. Here is an example project with my solution, which should work out of the box - and when in doubt, see readme.