I have a site on which users are supposed to jump back and forth between protocols (http vs https). For example, they may land on https://example.com/index.html, and then click through to http://example.com/test.html.
In order to accurately gauge the user behavior flow on google analytics, I need to treat both of these protocols as one single property in my GA setup.
google, however, makes you select a single protocol when defining a new web property. What is the best way to handle this? Let's assume https is my default - how can I trigger a pageview from the http site and have it be counted towards the https site's analytics?
I know there is a forceSSL option, but there is not much documentation around that:
By default, Google Analytics will match the protocol of the host page
when sending outbound requests. To force Google Analytics to always
send data using SSL, even from insecure pages (HTTP), set the forceSSL
field to true
Will this accomplish what I'm looking to do? Sending the data via SSL does not necessarily correlate to them recording the data as an SSL event.
My understanding of this issue is the following:
As far as Google is concerned, your HTTP and HTTPS properties ARE two separate entities.
The only way to lump them together is to force the entire site to use SSL, thus removing the HTTP property.
If this is an option, it will have the added benefit of increasing your search ranking.
Related
First, let me start with, I understand JavaScript can be tampered with so I'm not looking for a fool-proof solution. I have a public API that takes requests from external web applications. Sometimes the web applications are directly hitting our API and other times they jump through another API offered by some of our Partners.
In a partner scenario, we want to ensure the API requests are ultimately coming from specific URLs. My idea is this:
We're allowed to offer a script that the webapps can add to their sites so I was thinking we can set up an API Endpoint whose job is to capture the request, verify the origin (URL), and spit out a token that they must ultimately send later with the real API request through the partner API.
Is there a better approach or am I just really limited to the origin header to find out the website? I was hoping there were additional data points I can leverage on the client side to verify the traffic is coming from a specific URL
I'm trying to make a fetch to my API hosted locally from my GitHub page, but I can't due to the mixed content error. Is there a way to get around it? I'm not sending sensitive information or whatever and I don't need a response.
You need to either use HTTPS or HTTP across the board. You can't use half one and half the other.
I'm not sending sensitive information or whatever
HTTPS is not just about the encryption of the information, but also to ensure that you're connected to an authorized server. There are many ways connections get hijacked... including broken public WiFi access points with captive portals. In any case, the browser vendors don't give us much of a choice these days.
I'm writing a Chrome packaged app for diagnosing web services. I want to be able to send a GET request to a URL and look at the headers and data in the response.
My problem is if a users visits a site that has the HSTS header set before using my app, my app will then be unable send GET requests to the http:// URLs for that domain because Chrome will automatically convert the http:// URLs to https:// ones before the request is sent out.
Is there anything at all I can do to prevent this? I've looked into the webrequest API and webview tag but I'm finding nothing that lets me ignore HSTS.
Is it possible to use https://developer.chrome.com/apps/sockets_tcp for this (I would need to be able to support http, https and gzipped data)?
Is there anything at all I can do to prevent this?
Probably not. If you already tested <webview> and it shares the HSTS list with the browser, then the network layer will transparently rewrite this for you.
Is it possible to use chrome.sockets.tcp for this?
Technically, yes, HSTS shouldn't matter for that. Practically, you would need to implement something like wget+SSL+gzip from ground up (in JS, NaCl or a Native Host - but in the latter case you don't really need built-in sockets).
I am trying to connect to an external web socket server, which is not run by myself. I would like to connect to it from a localhost javascript file, therefore the origin header has null value.
I understand that this is a measure against cross-site forgery. However, since I am on localhost, I should be able to fake this, by getting Chrome to send a custom Origin header.
Is it possible? (if I need an extension, that is fine)
If not, what is my best option to achieve the above? Thank you.
Web pages cannot change the Origin header, but extensions can modify the request headers via the chrome.webRequest API. But ws:// and wss:// are not supported by this API, so this doesn't help unless the server also supports other means of communication via http(s) (e.g. long-polling).
There is still a solution though: Simply load a (known) web page at the desired origin in an iframe (e.g. https://example.com/favicon.ico or https://example.com/robots.txt) and use a content script to open the WebSocket from there.
The Origin header is one of the headers that are set automatically by the user agent (as part of the browser implementation), and cannot be altered programatically or through extensions. This makes sense because web service providers cannot allow random connections from localhosts.
You can connect to an external WebSocket only if you do it from a host explicitly accepted by the web service provider. Many headers cannot be trusted (because they can be overridden), but this is not the case with Origin as it offers security not only for users, but also for service providers against unwanted connections.
As far as I know this will not be possible, it would break the security guards against CSRF in Chrome.
If you were able to do that the whole concept of XHR would fall apart.
Here is an Extension you can use to manipulate header on the fly, but so far I have not been able to get it to manipulate socket headers.
Look here if you want to read more about this.
But this doesn't stop you from implementing your own client (in place of chrome) where you can literally send whatever headers you want, not sure if this helps you, sorry.
It depends how you want to use your chrome browser. Since you mention localhost I assume you develop and will use this for some kind of scraping. I suggest that you explore Chrome DevTools Protocol which will render (almost) any kind of protection useless because you use a real browser. CORS, Origin, Cookie or any arbitrary header value will be under your control, and you can send a custom header for xhr/websocket request(s). If you want to manipulate in a more advanced way you can use Network.continueInterceptedRequest. You might only want to start chrome using parameters like "--disable-web-security, --disable-xss-auditor, --disable-client-side-phishing-detection, --allow-insecure-localhost" more about such options at peter.sh. However, the last option require a plugin in order to spoof origin header so I recommend the first option.
I am designing a website that uses JavaScript Ajax XHR calls to retrieve dynamic data.
I have two C++ based applications that serve data on their own ports, and I have control of the ports that they use.
Dynamic Data is requested with HTTP 1.1 requests and data is returned with an HTTP 1.1 header, and I have control of the header data. Effectively, I have a custom HTTP server embedded in my dynamic data applications, so I have full control of both ends of the conversation.
If I choose two arbitrary ports to serve the dynamic data on, will the browser-based user have to open those ports on their firewall to allow the request from my web page?
For example, the web page would be served as www.mydomain.com/default.aspx, and within it, it would have Ajax XHR calls to make connections to www.mydomain.com:8080 and www.mydomain.com:8081 (or whatever port numbers are chosen).
Am I going to be blocked by the same origin policy?
Could I get away with using ports that are often open on firewalls, but not actively being served on my server?
What is the best way to work around this so that the user does not have to make firewall changes and does not get a cross domain warning? I'm hoping not to use iFrames if possible.
This topic may have been asked before, I have searched thoroughly but have not found anything that matches.
Wikipedia says you have to keep the same scheme, host and port but notes that some unnamed browsers do not enforce the port.
http://en.wikipedia.org/wiki/Same_origin_policy
The scheme is like HTTP:
The host name is like my.yahoo.com but there are some possiblilites to access any ???.yahoo.com in some browsers.
Port is pretty clear but notice that HTTP and HTTPS use different ports as the default.
This page is interesting:
http://www.w3.org/Security/wiki/Same_Origin_Policy