Iframe, not letting my customers to check the demo version.

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:

  1. Click login
  2. An XHR POSTs the credentials to https://pixeltalk.node.pixelnx.com/ and returns a 200
  3. A GET is made to https://pixeltalk.node.pixelnx.com/dashboard/, which returns a 302 to /
  4. A GET is made to /, which returns a 200 and the login form.

Without the iframe:

  1. Click login
  2. An XHR POSTs the credentials to https://pixeltalk.node.pixelnx.com/ and returns a 200
  3. 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.


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.


@lunatio I have the same problem, how could you solve this problem?

@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.


@lunatio @rosssimpson

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