The problem I am facing with the Iframe is when the user clicks on the live preview, and when they try to login my application for testing, they are not able to log in, but when they remove the Iframe, they are able to do so. The main problem is the environment is not set in the CodeCanyon. Can anyone tell me the solution, please.
Hi @kamleshyadav,
It’s hard to say without being able to take a look at the item in question. Often the problem is that your server sets a restrictive X-Frame-Options or Content-Security-Policy header that interferes with the behavior of your javascript when loaded in an iframe. Check the developer tools console for the preview page in question, looking for any obvious errors there.
I don’t know what you mean by “the environment is not set in the CodeCanyon”, could you explain?
Yes let me share you the link:
Please visit the link once, and click on live preview >> try to log in. It will not let you in, but when you will remove the Frame, and then try to log in, you will be able to do so.
Hi @kamleshyadav,
I’ve had a look, and appears that your site is reacting to the login differently when under the iframe and not.
With the iframe:
- Click login
- An XHR POSTs the credentials to https://pixeltalk.node.pixelnx.com/ and returns a 200
- A GET is made to https://pixeltalk.node.pixelnx.com/dashboard/, which returns a 302 to
/ - A GET is made to /, which returns a 200 and the login form.
Without the iframe:
- Click login
- An XHR POSTs the credentials to https://pixeltalk.node.pixelnx.com/ and returns a 200
- A GET is made to https://pixeltalk.node.pixelnx.com/dashboard/, which returns 200 and the logged-in content.
I’m not sure why the behavior is different here – it could be due to the Set-Fetch headers your XHR is sending:
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-origin
Check your server-side application and perhaps add some logging. Find out under what conditions the request to /dashboard returns a 302 response, and you should have your answer.
Thanks, Mate, for finding this many things, let me check at my side. If I can find something at my end.
I have one more Idea, that when we click on the Preview button, it redirects to the Frame, so what I can do is, when it redirects to frame, I put code to redirect to my server directly, so it will be directly going to my server, the Themeforest’s frame will not load at that time.
Hope you understand.
Our product is not working anymore either. Did you guys changed anything recently?
None of the _POST requests are working anymore.
The item in cause is: https://codecanyon.net/item/phpshort-url-shortener-software/26536593 - this is a Laravel based product.
Just to be sure & eliminate any chances that our product would have an issue, I’ve tested several other Laravel based products from the marketplace, an example would be: https://codecanyon.net/item/infyjobs-laravel-job-portal-script-with-website/28321916
Try pasting something into their Log-in input, a 419 Page expired session code would return.
This happened recently, this used to work 3-4 weeks ago.
Any help would be appreciated.
L.E: Curious enough, it still works on Firefox and Edge. On Chrome & Opera it does not.
L.E.2: Found the issue & the fix: Iframe, not letting my customers to check the demo version.
+1
I can confirm that this is the same for my products as well for some time now as some customers have told me that they can’t log in (but I could with the direct link of my demo, just not under the preview iframe).
Found the reason.
Starting with Chrome 85 (and probably the rest of the browsers will follow suit, Opera already did), browsers will automatically block all cookies that request SameSite=None on insecure cookies: https://developers.google.com/web/updates/2020/07/chrome-85-deps-rems#reject_insecure_samesitenone_cookies
For those wondering, the fix requires all cookies that have SameSite attribute set to None, to also be available only on Secure connections (HTTPS).
@rosssimpson - perhaps it’s time for Envato to consider a javascript based header/frame/floating thing (with a “Buy now” button or something), rather than an iframe. The restrictions around loading websites in iframes are becoming tighter and tighter and I wouldn’t be surprised if in the future, they’ll completely drop the support for it.
3 Likes
@Digit94Team I’ve explained the fix here: Iframe, not letting my customers to check the demo version.
1 Like
Thank you ! It work now
Hi @lunatio,
Thanks for the research, glad you found it!
Regarding your suggestion of a different implementation (which I agree with!), I’ve raised it with the appropriate product teams here. I don’t have any details to share at this point, but this iframe is something we’ve discussed before and will get some attention.
2 Likes
This solution will work for many users, but not all of them. There is also the “Block third party cookies” option in modern browsers, which is now enabled by default in some of the top browsers (e.g. Firefox and Chromium Edge).
For example, I have this option enabled on Chrome and cookies continued to be blocked until I turned it off, despite the above fix.
I don’t believe we should be changing the SameSite parameter. Instead, we need to urgently look for a solution that works for everyone. For example:
-
Change our live demo links to landing pages. The landing page will have a big button that opens the real live demo in a new tab.
-
Add code to our live demos which detects the iframe and ask the user to click the “remove frame” button at the top.
Unfortunately I can’t think of any elegant solutions here. Anything we do will affect UX until the root of the problem is addressed by Envato.
@baileyherbert - couldn’t agree more, that’s not something that I wanted to do either, but was forced-to. It’s basically a matter of months until all 3rd party cookies will be blocked, by default. Chrome said they’re doing this in phases, but other browsers already implemented it.
I believe that a JS snippet that would generate a top bar would be extremely difficult to implement, given the variety of approaches in designing a website (absolute positionings, fixed, sticky, etc).
Perhaps a better approach would be to show a message bubble (floating box) that would appear after X time, with one or two buttons (Buy now, View product) would be a better. It could even support some options, so when you’re adding the JS snippet, perhaps we could chose its positioning (top, bottom, left, right), and its color (light or dark), whether it drops a shadow or not, etc.
Here’s two quick mock-ups for both light & dark mode (look @ the bottom right corner), it doesn’t even need to be as intrusive as the current iframe:
1 Like
Hi @lunatio,
Those mockups look nice! I’ll pass the idea on to our product team, which is looking into this issue currently.
For what it’s worth, the reason why we’re still using the iframe is because the last time we ran an A/B test on the iframe (a year or so ago), there was a significant decrease in conversion when the iframe and “buy now” button was removed (meaning fewer item sales). Our analysis showed that once a user navigated away from Market to the author’s preview site, they didn’t know how to get back and actually purchase the item. Some authors include a link back to the item page, but most do not. “Frame escape” code (which no longer works) or instructions will have a similar effect.
The iframe is obviously not an elegant solution, and as browser vendors move to more secure-by-default positions, it will only get worse. We have both product and development folks looking into a better solution now, and when we’ve got something to announce there’ll be a post here on the forums.
Until then, thank you for your continued patience, and all we can suggest is to set SameSite=None on your demo sites if you need cookie behavior.
Hi @rosssimpson,
The problem is that not even SameSite=None fixes it anymore, because some browsers, such as Firefox, already block 3rd party cookies, by default. You’d have to go into your browser settings to manually disable this setting before being able to benefit from the beforementioned setting.
This is actually worse than expected, as users are currently viewing an item that appears not to be working, regardless of whether or not we set SameSite=None policy, potentially making them never to return to that item page again.
A quick fix would be to have a check box to opt out of the iframe, and let us implement the floating button ourselves.
I hope you guys are taking this as a #1 priority, and not wait until Chrome introduces this too as that would be too late: https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html - we’re already at the half of the timeline, so we shouldn’t really be too far from it.
1 Like
Hello All 
Hope you guys are doing good during these strange times.
The SameSite attribute tells browsers when and how to fire cookies in first- or third-party situations. SameSite is used by a variety of browsers to identify whether or not to allow a cookie to be accessed.
Method 1 : For PHP based Apps
if (PHP_VERSION_ID >= 70300) {
$cookie_options = array(
'expires' => time() + 60*60*24*30,
'path' => '/',
'domain' => '.domain.com', // leading dot for compatibility or use subdomain
'secure' => true,
'httponly' => false,
'samesite' => 'None'
);
setcookie('cookiename', 'cookievalue', $cookie_options);
} else {
setcookie('cookiename', 'cookievalue', time()+(7*24*3600), "/; SameSite=None; Secure");
}
Method 2 : Using .htaccess file
Header always edit Set-Cookie (.*) "$1; SameSite=None; Secure"
Method 3 : Ngnix Configuration
location / {
# your usual config ...
proxy_cookie_path / "/; secure; HttpOnly; SameSite=none";
}
Method 4 : Using Local Storage
Thanks to Schiocco
Big +1 from me! As I mentioned in a similar thread, the SameSite=None fix does not work for me. All of your demos are still broken on my side, with third party cookies disabled (which is increasingly enabled by default). Your demos are still broken and there is no fix. An alternative is needed ASAP.
1 Like
2 years later, literally zero updates on this matter. We’re forced to break the iframe to have working demos. Whatever happened to you guys?