my serviceworker is listening on fetch, and for all the FetchEvent requests with navigate mode, i want to do something, but excluding the ones that come from iframes src.
I've inspected the event and the request objects and did not found a way to check it, is it possible to know?
No, that information is not exposed in the FetchEvent.
Additionally, there's no distinction made between full-page and iframe clients when determining the ClientType value. Both come back with a ClientType of window.
Related
I am wondering how to make sure that I only ever show/render the content (send the code to the client) if the content is loaded in an iframe in a real browser, similar to the way Facebook checks when to display their like buttons and other social utilities.
There, when trying to simply load the content using curl, even when sending cookies, session details and user agent details, it still returns nothing. When trying to load the content outside an iframe, one receives nothing. How can that be achieved? I guess it is all but a simple process that involves multiple steps. I am especially interested in the first one, namely how to detect that it is really sent from a browser and not simply curled.
Thanks.
There is no way for your server to detect if it was sent using browser or curl, as the headers are easily forged.
i heard that , if your asp.net page is inside a iframe, and u want to get the parent url, you can achieve this by using the referrer?
i tested is okay, and found that the window parent url will included in the referrer when called the iframe content
Request.UrlReferrer.ToString();
Assume that i can only use server side to achieve
I just want to ask is that way safe?
Any chance to lost the referrer url in this case
The browser is not guaranteed to send the referer. It's all up to the browser/configuration/extensions/proxies and whatnot between the request and your server.
If the user navigates to a different page within the iframe, the referer will point to whatever the user came from.
All in all, never use the referer for any logic that may fail if it's not there or if it has an unexpected value.
You can do this but it is not entirely in ASP.Net.
You would have to get the referrer from Javascript and pass that to the iFrame.
One of the 2 following calls would be what you are looking for.
top.document.referrer
or
parent.document.referrer
My web-app records users via webcam and microphone. I want to use HTML/JS for the controls and content, so I created two separate Flex modules:
* A "Webcam Setup" module that lets you choose your camera and mic input devices
* A "record" module that lets the user record and submit the recording
When I embed either of these on the page, since they access the user's Camera/Mic object, Flash shows the Privacy dialog that says "[mysite] is requesting access to your camera and microphone. If you click Allow, you may be recorded."
The problem is, if I answer Yes in the Setup module, and later add the Record module to the page using Javascript, it again shows the Privacy dialog.
Is there a way to avoid the second privacy popup?
I would think that saying "Yes" for [mysite] would store that permission for at least that session, but apparently not.
What I've tried
I tried combining them into one SWF, adding it to the page once and moving the DOM element with jQuery's append() function when needed. When I move it, however, it reloads and asks me again.
Imagine if [mysite] was, say, blogger.com or livejournal.com (or, if it were still around, geocities.com). Would you want a "yes" response on that site to be good for every page under that domain?
Rememeber, just because you promise (cross your heart & hope to die) not to abuse the security hole you request, doesn't mean they can allow you to have that security hole.
Eventually, I found a usable workaround, similar to what I originally tried (above).
I combined the setup and record modules into one SWF. I first show the setup screen. When the user hits the Continue button on my page, Javascript calls a function in the SWF to swap to the Record screen.
I then move the <div> containing the Flash object to another location on page using absolute positioning, and resize the object.
Previously, I was trying to use jQuery's append() function to move the div within the DOM, and that was causing the SWF to reload. Just changing position and size does actually work.
You could build the "record" component to simply send and receive signals using an API you've created for your "setup" component (which has already been authorized, meaning one auth & two swfs) by using the LocalConnection class:
http://livedocs.adobe.com/flex/3/langref/flash/net/LocalConnection.html
This seems far closer to best practice than the other implementations mentioned, which smell a bit hacky and would probably confuse anyone who may inherit the codebase in the future.
For a specialized purpose with Aweber regarding a newsletter subscription, I have a page loading a nested IFRAME inside, and both reside on the same domain. (Many other stackoverflow posts talk about different domains, but this question deals only with the same domain.) I need a cross-platform way (including browsers as old as the dawn of IE6) for the two to communicate.
For example, someone fills out name and email and clicks a checkbox, and the hidden IFRAME next to the checkbox sits in a setInterval() loop watching for that. When it receives notification, it grabs the name and email and does a form post.
I thought at first that I could just drop a cookie in the parent page, and then the IFRAME child could then sit in an interval watching for that cookie. But my tests show that this won't work. The cookie gets created -- but the IFRAME can't see it. So, I tried the meta-refresh technique in the IFRAME, and again it couldn't see that cookie for some reason.
The only solution I can come up with is that the parent page will take the checkbox click (we use jQuery) and do an AJAX data push to the server into a database. The IFRAME can then check on an interval back to the server via AJAX to see if the database value has changed, and react to it if so. But this seems like an over-engineered solution and I'm looking for an easier alternative that works cross-platform, even in earlier browsers from the timeframe of IE6 and forward.
It's much more simple: In the iframe, you can access the parent variable, which contains the parent window. So you can use parent.document to find the form, read the values, etc.
I'm trying to post to the login form of an application on another subdomain of my site. It's a third party app that I don't have source access to.
I know that you can't access most features of a cross-domain iframe because of same origin policy. All I need to access, however, is the URL that's been redirected to (via JavaScript) within the iframe. It has a session token that I want to pass through.
That seems like something that might be safe enough to be allowed, but I haven't found a way to do it yet. I'm using jQuery, and I've tried $('iframe').contents(), but I seem to have no permissions at all on that object. I've also checked $('iframe').attr('src'), but it remains as the pre-redirect URL. Is there another way?
No, you don't have access to any properties within an iframe. You only have access to the outer positioning and styling properties.
This is why frames are such a pain to work with. I usually only use them if I don't care what is done within them.
Can you not do a server-side authentication and token passing? Instead of having the client do the authentication, can you not do that on your server? You may need to do some extra work to create the HTTP request and parse the response, but you avoid any iframe issues.
Bottom line is iframes probably aren't the best to rely on(especially when it comes to cross-browser functionality) for important things like authentication.
Try this example (method 2) in which the author sets up another iframe inside the first, loading a page at the original domain.
The inner page is allowed to call javascript on the outer parent, since they are loaded in the same domain.
Simply load the inner page with appropriate parameters, which can be passed on to the parent.