I'm working on a client site and we pinpointed that their site loads slower on Chrome than other internet browsers:
We have run a pagespeed report on Google PageSpeed through Lighthouse as tried opening the site on different browsers in different locations and different computers
Fetch time: Apr 23, 2019, 8:13 AM GMT+2
Device: Emulated Nexus 5X
Network throttling: 150 ms TCP RTT, 1,638.4 Kbps throughput (Simulated)
CPU throttling: 4x slowdown (Simulated)
User agent (host): Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
User agent (network): Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3694.0 Mobile Safari/537.36 Chrome-Lighthouse
CPU/Memory Power: 664
This is the first time we've seen this on a client site, specifically Chrome being slower. Could anyone provide a possible reason why? OR has anyone else seen this before?
Thanks in advance
By the way, if this is the first time you see the output shown above, than take note of Network throttling and CPU throttling. They are options that simulate a slow network and CPU overload, for a more realistic test environment.
There is ways to disable them, both on the Lighthouse CLI and from DevTools.
And in general, there is always going to be variability on the test results: https://github.com/GoogleChrome/lighthouse/blob/master/docs/variability.md
I had to update a form on a certain webpage to change something i wanted.
I failed to do so, but instead of sending a simple text reply saying 'This cannot work' for example, they sent a whole JSON response on the display.
I'm just curious, does this response pose any security vulnerabilities for either me or the server i contacted to process my request?
P.S. The '***'s in the response are so because I'm not sure if providing that info is the right thing to do.
However, even without it, the response is fairly intuitive.
This is the response:
{"name":"StatusCodeError","statusCode":409,"message":"409 - [object Object]","error":{"status":"failure","message":"Email already taken.","code":91,"data":null,"error":{"message":"None"}},"options":{"uri":"*********","method":"POST","headers":{"Authorization":"Bearer *********=","Cookie":"*********=;cm_sub=denied","User-Agent":"********","Accept-Language":"en-US","Original-Accept-Language":"********","X-********-InstallId":"*****","X-*****-AppState":"active","X-*****-Parent-Rid":"********","X-*****-Root-Rid":"********","X-*****-Rid":"*****","X-Pixel-Ratio":1,"X-*****-App-Type":5,"X-Prefer-User-Locale":"1","X-Real-Ip":"********","X-*****-Real-Ip":"*****","X-*****-Csrf":"********","X-*****-Browser-Extension-Installed":"false","X-********-Referrer":"********","X-Bot":"false","X-Referrer":"********","X-Url":"********"},"form":{"base_scheme":"https","client_id":1431601,"timestamp":*****,"country":"US","email":"*****","oauth_signature":"********"},"traceId":false,"parseJson":true,"resolveWithFullResponse":true,"json":true,"simple":true},"response":{"statusCode":409,"body":{"status":"failure","message":"********","code"********,"data":null,"error":{"message":"None"}},"headers":{"server":"nginx","date":"Sun, 10 Mar 2019 16:08:31 GMT","content-type":"application/json","content-length":"112","connection":"close","*****-version":"*****","x-content-type-options":"*****","x-frame-options":"DENY","*****-generated-by":"********"},"request":{"uri":{"protocol":"http:","slashes":true,"auth":null,"host":"*****","port":"*****","hostname":"localhost","hash":null,"search":null,"query":null,"pathname********","path":"/v3/users/settings/","href":"********"},"method":"POST","headers":{"Authorization":"********","Cookie*********","User-Agent":"Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/******** Safari/537.36","Accept-Language":"en-US","Original-Accept-Language":"en-US,en;q=0.9","X-*****-InstallId":"********","X-*****-AppState":"active","X-*****-Parent-Rid":"********","X-*****-Root-Rid":"*************","X-*****-Rid":"*****","X-Pixel-Ratio":1,"X-*****-App-Type":5,"X-Prefer-User-Locale":"1","X-Real-Ip":"*****","X-*****-Real-Ip":"********","X-********-Csrf":"********","X-*****-Browser-Extension-Installed":"false","X-********-Referrer":"*************","X-Bot":"false","X-Referrer":"********","X-Url":"********","content-type":"application/x-www-form-urlencoded","accept":"application/json","content-length":179}}}}
Here's what I learned from this server response. The first thing I noticed is your protocol is using http.
"protocol":"http:"
HTTP is a plaintext and unencrypted form of communication. This is important to note because if someone is sniffing your traffic, they will be able to read the transmission as you have posted it here (without the *****'s blocking sensitive data).
The next thing I noticed is your authorization token.
"Authorization":"Bearer *********="
Given that the message is in plaintext, an attacker will be able to steal your token. Using this token an attacker can communicate with the server as an authorized user, gaining access to (and possibly the ability to modify) private information.
On the flip side, since we assume the attacker has sniffed your unencrypted traffic. They can also make note of your client's computer/ browser information:
"User-Agent":"Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/******** Safari/537.36"
From this info, the attacker can gather that the client is using windows 8.1 and what browsers/versions are installed on the client's computer. With these system specs, the attacker can launch a targeted attack on the client's computer (especially if you have an outdated/ insecure OS or browser version).
So to answer your question, yes there are security vulnerabilities for both the client and server.
However, simply switching from HTTP to HTTPS would make a big difference in limiting your exposure.
I am trying to resolve the following error:
Error communicating with the Windows Phone Dev Center. Set the correct date and time on the phone, check your Internet connection, and try again. (ErrorCode:0x64).
I've checked our developer account and can see there are no devices unlocked so we haven't hit our limit. (We did have 3 devices previously unlocked but they have since been deactivated and removed from the account).
The date/time are correct and the device is connected to a valid Wi-Fi with Internet access.
Here is what I have done:
I have rebooted the PC (Windows 10)
I have rebooted the phone (Windows 8.1)
On the phone I have switched the date/time settings to manual and then back to automatic
I've factory restored the device to original settings
I've checked local host files for anything related to windows/Microsoft/development
I've restarted the IpOverUsbSvc service many times
There was a server side problem with the Dev Center that blocked device unlocking. It should be fixed now, so try again, though it may take some time to propagate.
In general you should contact Microsoft Dev Center Support with problems like this as it's not something anybody outside of Microsoft can help with.
I just got this.
Nothing worked until I finally connected to a Internet capable wireless network.
Hope this helps someone else.
TFS 2013
Windows Server 2012
IIS 8.5
Application Request Routing (ARR)
I'm using ARR for a reverse proxy to reroute any requests for a URL on that server to the IP address that I have setup for TFS on that server.
Everything works great, except in Chrome (don't get to say that very often).
When browsing the web version of my TFS install and visiting a "Team Room", I get a SignalR error in the Chrome console:
403 (Forbidden: SignalR cross domain is disabled.)
The same link in FF and IE works fine. Also, if I visit the Team Room link directly via the TFS IP address (bypassing ARR), it works fine.
I've tried a bunch of different things to solve the issue.
Adding this header to the web.config for TFS
<add name="Access-Control-Allow-Origin" value="http://tfs.mydomain.com"/>
Setting the connection URL of the SignalR connection in JavaScript and using JSONP like so:
$.connection.hub.url = "http://my.ip.address:8080/tfs/signalr";
options = ({jsonp: true})
$.connection.hub.start(options)
I even tried another approach I found online which disabled the cache on ARR.
Many solutions out there say that I should enable cross domain requests for SignalR on the server, however since this is for a TFS install, I don't have the freedom to modify the binaries for TFS (as far as I know) and I wasn't able to find a way to do this on the client by looking at the SignalR API.
The only other answer I came across for this problem was that Chrome is bugged and not to use it (which is undesirable).
Does anybody know how I can use Chrome to access TFS team room functionality?
I don't know the answer, but I have the same problem and some information.
I used Fiddler to examine the HTTP request to see what was different between the requests sent from Chrome and from IE. Chrome sends an "origin" header along with the "referrer"; IE doesn't. I used Fiddler's Filter option to dynamically remove the "origin" header and Chrome works normally as long as Fiddler is capturing.
These are some of the headers sent from Chrome:
Origin: https://[domain]
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: https://[domain]/tfs/_rooms
Removing the "Origin" header in Fiddler's filters allows Chrome to work.
This is a maddening problem I come across once or twice every few months: websockets aren't working right. Here's the facts:
My browser can connect to my local (loopback) server, but when the browser sends messages, the server never gets them.
This has happened a few times to me before in the last 6 months - it always seems to start working without any change on my end, and for no apparent reason
This started happening right after I restarted my computer...
http://www.websocket.org/echo.html also doesn't work
The connection is being closed with code 1006, wasClean is false, and reason is a blank string
Firefox and chrome both have this problem
I've confirmed that turning off my firewall (windows 7) doesn't change anything
I've also confirmed that a node.js client and server works on linux (centos 6 VM running inside my windows machine), but the same client and server setup doesn't work on my windows machine (tho when I tested on a different windows 7 machine, it works fine)
Here's the info from chrome's network tab:
Request URL:ws://echo.websocket.org/?encoding=text
Request Method:GET
Status Code:101 Web Socket Protocol Handshake
Request Headers CAUTION: Provisional headers are shown.
Cache-Control:no-cache
Connection:Upgrade
Cookie:__utma=9925811.1690403310.1402691326.1402691326.1402691326.1; __utmb=9925811.13.10.1402691326; __utmc=9925811; __utmz=9925811.1402691326.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
Host:echo.websocket.org
Origin:http://www.websocket.org
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
Sec-WebSocket-Key:eH9OcxKQ/I6S+IkzY+HsaA==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36
Query String Parametersview sourceview URL encoded
encoding:text
Response Headers
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:x-websocket-protocol
Access-Control-Allow-Headers:x-websocket-version
Access-Control-Allow-Headers:x-websocket-extensions
Access-Control-Allow-Headers:authorization
Access-Control-Allow-Headers:content-type
Access-Control-Allow-Origin:http://www.websocket.org
Connection:Upgrade
Date:Fri, 13 Jun 2014 21:36:59 GMT
Sec-WebSocket-Accept:d0eOTUUxMpkKsI6x9RJ+vGBxl3w=
Server:Kaazing Gateway
Upgrade:WebSocket
Is there something that looks wrong in those headers? Anyone have any idea what might be going on? Its like my computer is blocking websocket messages but not connections.
UPDATE:
Unbelievable. I literally have taken no action to correct this. I haven't restarted, changed settings, or installed or uninstalled anything. But the problem is gone - messages now go through as normal. Why is this happening?
Try to enable WebSocket Protocol.
Go to :
Control Panel -> Program and fonctionality -> Enable or disable windows features