Problem/Motivation
Using Webform Share’s (6.0.0-beta2) javascript option to embed an https form onto to a non-drupal page served on http, I’m seeing the resize fail, apparently because of the drupal-side redirect to https. Because the javascript option used the protocol by which the parent page is accessed, the shared form loads in but only a portion of the fields display, as in the attached screenshot.
Using the “Resizing iframe” option in Webform Share does the same thing, but in that case I can add the https protocol into the frame’s src attribute and the frame loads and resizes as expected. The “JavaScript” option, though, always generates a protocol-less frame src, even when I add the protocol into the src attribute of the script tag.
Steps to reproduce
End user experience
1. On a drupal site which forces https, create a webform, enable sharing, and copy the javascript share code.
2. Paste the code into a parent page and access that page over http.
3. Observe the form is only partially displayed.
4. In the parent page, amend the content of the embed script to include https as the protocol.
5. Reload the page.
6. Observe the same behavior as #3.
Proposed resolution
Amend the generated javascript share script to respect a protocol if included in the script's src attribute.
Remaining tasks
TBD
User interface changes
N/A
API changes
TBD
Data model changes
N/A
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 3186943-6.patch | 877 bytes | barrett |
| #4 | 3186943-2.patch | 874 bytes | jrockowitz |
| #2 | 3186943-2.patch | 874 bytes | jrockowitz |
| Mozilla_Firefox.png | 18.48 KB | barrett |
Comments
Comment #2
jrockowitz commentedI don't have an easy way to replicate this issue. Attached is my best guess at the solution.
Comment #3
jrockowitz commentedThis issue should be fixed 8.x-5.x
Comment #4
jrockowitz commentedComment #5
barrett commentedNo joy on the patch, but I think it's the right direction.
Using the javascript location.protocol is getting the protocol by which the parent page is requested, so http in the case I'm encountering, when it needs https. I think changing that in the controller to use Request::getScheme() instead will allow the script to be accessed on https and result in an iframe that uses an https source.
I'll test that out locally and roll a new patch if it works.
Comment #6
jrockowitz commentedYes. I need help with this patch. Thanks
Comment #7
barrett commentedHere's a variant of your patch that uses $request->getScheme(). It's working in my testing, thus far.
You can see an example of what the script spits out at https://www.datasmith.net/webform/test/share.js
Comment #8
jrockowitz commentedAn issue with including the schema is if a website is behind a load balancer where the HTTPS request terminates at the load balancer and each server is getting an HTTP request. I hope that makes sense.
We might want to let this patch sit around and see if other people are running into this issue.
Comment #9
barrett commentedYeah, I see what you're saying. I don't have any objection to letting the issue sit for a bit and seeing if anyone else has different results.
I'm testing on Acquia hosting, where SSL is terminated at the balancers, and this patch seems to be working. I _think_ that's because getScheme() calls isSecure() which checks the x-forwarded-proto header. Certainly possible though that other server configurations wouldn't work the same way.
Comment #10
barrett commented[correcting component which I somehow set to "translation" by mistake]
Comment #11
jrockowitz commentedHmm... maybe we should just apply this patch to 6.x and call it a day.
Comment #12
jrockowitz commentedHere is the plan...this will be committed immediately after the next stable release of 8.x-5.x and 6.x in the hope that people will discover any regressions via the dev and beta release.
Comment #15
jrockowitz commented