Anyone ever had an issue when embeding a docusign signing ceremony in an iFrame?
I'm trying to test docusign embed signing by using an iFrame. But the browsers (tested on Chrome, Firefox) are refusing to render the url.
I get the embed url (which looks like https://demo.docusign.net/Signing/MTRedeem/v1/XXXXXXXXX?slt=XXX) from DocuSign and then sets this url to iFrame source on my website. But it just shows a blank page nothing comes up (instead of embeding in an iframe if I just paste the url in the url bar it renders fine). If I check the console logs in Google Chrome (on win10) I see an error
Refused to display 'https://account-d.docusign.com/recipient/auth?ui_locales=en' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
<iframe src='https://demo.docusign.net/Signing/MTRedeem/v1/XXXXXXXXX?slt=XXX' height='900' width='900'>
</iframe>
If I observe the network tab the following redirects are happening:
Request URL: https://demo.docusign.net/Signing/MTRedeem/v1/XXXXXXXXX?slt=XXX
Request Method: GET
Status Code: 302 Found
Response Headers
Location: https://account-d.docusign.com/managed_token/v1/redeem/?slt=XXX
Request URL: https://account-d.docusign.com/managed_token/v1/redeem/?slt=XXX
Request Method: GET
Status Code: 302 Found
Response Headers
Location: https://demo.docusign.net/Signing/StartInSession.aspx?code=XXX
X-Frame-Options: SAMEORIGIN
Request URL: https://demo.docusign.net/Signing/StartInSession.aspx?code=XXX
Request Method: GET
Status Code: 302 Found
Response Headers
Location: https://demo.docusign.net/Signing/ActivateSecurityChecks.aspx?insession=1&ti=XXX
Request URL: https://demo.docusign.net/Signing/ActivateSecurityChecks.aspx?insession=1&ti=XXX
Request Method: GET
Status Code: 200 OK
Response Headers
Set-Cookie: BIGipDocuSign_Demo_Signing=XXX
X-DocuSign-Node: XXX
Request URL: https://account-d.docusign.com/recipient/auth?ui_locales=en
Request Method: GET
Status Code: 200 OK
Response Headers
X-Frame-Options: SAMEORIGIN
X-DocuSign-TraceToken: XXX
X-DocuSign-Node: XXX
Note: I followed this sample from docusign's official examples.
EDIT
RecipientViewRequest:
{
"AssertionId":"logging in event id",
"AuthenticationInstant":"1\/29\/2020 11:09:26 AM",
"AuthenticationMethod":"password",
"ClientUserId":"logged in user id",
"Email":"my-email#mydomain.com",
"ReturnUrl":"https:\/\/subdomain.mydomain.com\/recieve",
"UserName":"signerFirst lastName",
"XFrameOptions":"allow_from",
"XFrameOptionsAllowFromUrl":"https:\/\/subdomain.mydomain.com"
}
EDIT 2
If I recall, the embeding method had worked for me in the past while testing.
This behavior of refusing to render in iFrame has started fairly recently. Maybe they have changed on their end during last month.
In general, iframes are discouraged due to compatibility and difficulty in troubleshooting. The recommendation is to instead redirect the user to the URL and then catch the returnUrl redirect upon completing.
That said, there are two relevant parameters in the Envelopes::CreateRecipientView call
"xFrameOptions": "allow_from",
"xFrameOptionsAllowFromUrl": "https://example.com"
where the xFrameOptions parameter should be "allow_from" to enable this functionality, and AllowFromUrl should be the domain of your site.
Related
It's a little difficult for me to search for a response to my question because so many people are asking a different question that uses most of the same words.
I'm creating a site on Wix and using their Backend Code platform to create an HTTP endpoint. The HTTP endpoint sends an email to me using nodemailer, a feature which is not available in the browser.
While testing I set the Endpoint to be wide open using these headers.
{
"Accept": 'application/json',
"Access-Control-Allow-Origin": "*",
"Access-Control-Allow-Methods": "POST, GET, OPTIONS",
"Access-Control-Max-Age": "86400",
"Access-Control-Allow-Headers": "Content-Type"
}
And when I send the fetch request to the HTTP Endpoint on localhost, everything works as expected.
Now, Wix requires custom HTML code to be embedded in an iframe. Developers don't have direct access to the code on their site. When I embed the code with the fetch request into an iframe and click the button to send the fetch request I get blocked by CORs.
I can see, in the Chrome Developer Console that Chrome is sending the fetch request, but along with the first Options request Chrome isn't getting the correct headers from the Endpoint. The request is subsequently blocked.
Is there any reason why being embedded in an iframe would cause this code not to work?
If this is impossible, which I fear, what other way is there to send an email from an iframe?
when i add profile of supplier on localhost working fine. and API POSt method is working fine.
but after publish of project on server getting 400 error when i add profile of supplier.
and in response getting this.
The requested resource does not support http method 'GET'.
with 400 status
i have attached images of errors.
Project url is :
https://localefood.maqssoft.com
test-user : supplier#gmail.com
password: a#123456A
This link has the same issue that i am looking for but not give the solution of problem.
https://forums.asp.net/t/2129791.aspx
enter image description here
Make a POST request with POSTMAN.
List item Use the same URL as you did for the GET request steps above, but now choose POST to be the selected HTTP method.
Click the Body tab just under the URL, then choose the raw radio
button and JSON (application/json) from the type dropdown menu:
You may note that a new Header gets automatically added to the
request. Requests that send data need a header telling the API what
kind of data is being sent. Click the Headers tab to see the
Content-Type: application/json header:
Click Send.
If you have recently submitted a request you may not be asked to
authenticate again. If you get an Unauthorized error, request a new
access token and click Send again.
Chrome version: 57.0.2987
Actually, in older Chrome version I also have this problem.
I added Authorization on Request Header with my access token,
fetch('https://example.com/endpoint', {
method: 'GET',
headers: {
'Authorization': 'Bearer ' + accesstoken
}
})
I always get Access-Control-Allow-Headers:authorization on Response Header in Chrome
Besides, My fetch is always Request Method:OPTIONS (not display GET), then Status Code is 200 OK in Chrome
But if I run the same fetch code in Firefox (ver 52.0.1 ), everything works great. I can add Authorization on Request Header correctly. It won't display Access-Control-Allow-Headers:authorization on Response Header in Firefox. It will display Authorization: Bearer accesstoken on Request header.
The server side already processed CORS for my request header..
This is a Chrome bug or my code fault? How should I do to make Authorization on Request Header correctly in Chrome?
Below image is the detail Network in Chrome dev tool:
Below image is the detail Network in Firefox dev tool:
As #stackdave said, browser send OPTIONS request before GET request when cross-domain ajax. Then browser will wait server response. My situation that the server didn't response, so browser just stop OPTIONS status. Server need to handle this issue, it's still CORS issue, not fetch api bug or issue.
browser will send before a OPTIONS request, without the authorisation token, and then will send the real request
http://www.w3.org/TR/cors/ See http://metajack.im/2010/01/19/crossdomain-ajax-for-xmpp-http-binding-made-easy/ for a bit more info
I need to make an HTTP GET request with custom request headers in-browser and process the result as it streams in. The Fetch API is ideal for this:
fetch('https://example.com/resource', {
method: 'GET',
headers: {
'X-Brad-Test': 'true'
},
cache: 'no-store',
mode: 'cors'
}).then((res) => {
const reader = res.body.getReader();
// etc.
});
This works quite well. Since there are custom headers, the browser pre-flights the request with an OPTIONS request to /resource. I have configured my server to respond with a 204 No Content and the following headers:
Access-Control-Allow-Headers: X-Requested-With, Range, If-Range, X-Brad-Test
Access-Control-Allow-Origin: *
The browser is happy with this, then makes a GET request, the server returns a 200 OK with the data, and the browser allows me to access the response headers and body.
The problem comes in when there is a redirect. The OPTIONS request succeeds with the 204 No Content and the same headers as before. The browser makes the correct GET request, and on the server I send a 302 with a Location: header. Chrome throws the following error:
Fetch API cannot load https://example.com/resource. Redirect from 'https://example.com/resource' to 'http://some-other-origin/resource' has been blocked by CORS policy: Request requires preflight, which is disallowed to follow cross-origin redirect.
This was unexpected, and seems nonsensical to me. I expected the browser to follow the redirect, and do another pre-flight request for this new location, but it didn't do that.
Stranger still is that I can sort of hack around this client-side. I can make an HTTP request without my custom header, figure out where I ended up after redirects by looking at the Response object, then make a second request at the new target with my custom headers. This doesn't work in all cases of course, and I'd rather not rely on this hack. I'd rather find a proper way.
Two Questions:
What is the proper way to allow the client to follow redirects? Is there some sort of Access-Control-* header I can use?
Why does this restriction exist? What security issue is prevented by not following and running pre-flight on the followed URL?
Supporting redirects to requests that require a preflight is very recent change to Fetch (which defines CORS).
https://github.com/whatwg/fetch/commit/0d9a4db8bc02251cc9e391543bb3c1322fb882f2
I believe some implementations have started adjusting their implementations, but this will take some time to reach everyone.
I have a ASP.Net WebAPI application using:
Microsoft.AspNet.Cors - 5.2.2
Microsoft.AspNet.WebApi.Cors - 5.2.2
Microsoft.AspNet.WebApi - 5.2.0
Please note I had some problems displaying the http address with stackoverflow so it might look a bit strange on this question:
I have set the following:
var cors = new EnableCorsAttribute("`http://localhost:4181`", "*", "*", "X-Custom-Header");
config.EnableCors(cors);
and in my controller:
[EnableCors(origins: "`http://localhost:4181`", headers: "*", methods: "*", exposedHeaders: "X-Custom-Header", SupportsCredentials = true)]
[OverrideAuthentication]
[HostAuthentication(DefaultAuthenticationTypes.ExternalCookie)]
[AllowAnonymous]
[Route("ExternalLogin", Name = "ExternalLogin")]
public async Task<IHttpActionResult> GetExternalLogin(string provider, string error = null)
When I access the site with IE11 I can login to the site (Ajax login) the correct response is sent back but I don't see any customer headers saying Access-Control-Allow-Origin. IE accepts what came back and takes me to the next page.
When I access the site with Chrome I can login to the site (Ajax login) the correct response is sent back but I don't see any customer headers saying Access-Control-Allow-Origin. Crome does not accept the resonse and even though there's a 200 code returned it does not go to the next page. Instead it gives this message in the console:
XMLHttpRequest cannot load http://localhost:3048/Token. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4181' is therefore not allowed access. The response had HTTP status code 502.
When I check with fiddler both the IE and the Chome calls return the correct access data from the login but Crome goes no further than displaying the console error message.
Add the following line of code to GrantResourceOwnerCredentials, which will add the header to the response.
context.OwinContext.Response.Headers.Add("Access-Control-Allow-Origin", new[] { "*" });
Check my answer here ASP.NET WEB API 2 OWIN Authentication unsuported grant_Type
and my article here, where you can find a working project with CORS enabled.
I have had problems setting
Access-Control-Allow-Origin: *
Some browsers do not accept *, but requires the response to contain the domain name of the originating request, like this:
Access-Control-Allow-Origin: stackoverflow.com
Therefore (and for security reasons): On the server, read the domain the request originates from, compare this against a whitelist, set Access-Control-Allow-Origin to the domain the request originates from.