I wanted to check whether system uses proxy or not to make ajax requests in chrome app.
i tried the following chrome app api
chrome.proxy.settings.get(
{'incognito': false},
function(config) {console.log((config));});
i am always getting this result irrespective of adding proxy in browser or not
{"levelOfControl":"controllable_by_this_extension","value":{"mode":"system"}}
mode value always as system and direct is not coming while proxy disconnected
Related
StackOverflow Community,
I have a problem that someone may have solved before, but I find it truly confounding.I'm running a flutter web server on a vm in Azure with
flutter run --release -d web-server --web-port 8081
After getting CORS error attempting to hit Maps or Places API, I elected to run another instance of NGROK with the --host-header=rewrite flag, as I have done for other APIs to avoid this CORS error. This works fine with all of the other APIs we are hitting.
However, when serving this app, I still get a very similar CORS error, identifying items hidden:
Access to XMLHttpRequest at 'https://hidden1.ngrok.io/maps/api/place/autocomplete/json?input=s&key=hidden&sessiontoken=hidden' from origin 'https://hidden2.ngrok.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.Hidden1 is my maps API redirect and Hidden2 is my app's dev redirect.
Am I still getting this error because I somehow need to serve place autocomplete, in this case, from the same subdomain as the app's subdomain?? I'm confused, because this is not a constraint of any other APIs I remember using in the past.
I still get a 200 response with this CORS error, but chrome refuses to do anything with it unless I use a CORS-enabling extension.
If I do need to redirect Places and the app's Web Server through the same URL, are there any recommendations for doing this?
Thanks in advance for your time and thoughts..
Background: I'm trying to send a request through cy.request and I get a different response from what I receive when I send a presumably similar request through PostMan. According to the debug information that Cypress writes to the console, I couldn't spot the difference. Therefore I wanted to look at Fiddler and see if I can spot the difference when looking at the raw requests side by side.
However, when I opened Fiddler I realized that I don't see any traffic from it, including the navigation to the home page using cy.visit().
Any ideas why I can't see the traffic in Fiddler, and if there's some way to capture it?
Fiddler is a proxy, it has to be explicitly used by an application, otherwise it will not be recogized by Fiddler.
There are three reasons that often cause that traffic is not visible in Fiddler:
The Windows application explicitly ignores the Windows/IE proxy settings. Usually such apps have an own proxy configuration. Configure it manually to use Fiddler. A common example of such an application is Firefox.
If you have activated the "Act as system proxy at startup" Fiddler changes the proxy settings while running. Any application that is already running when Fiddler starts may have already cached the old proxy configuration and therefore does not use Fiddler. Therefore start Fiddle before any program you want to capture.
The setting "Act as system proxy at startup" is AFAIK user specific, therefore any apps running on a different user or service account are not affected. You have to manually configure them to use Fiddler.
Cypress does not actually make an XHR request from the browser. Cypresd making the HTTP request from the Cypress Test Runner (in Node). So, you won’t see the request inside of your Developer Tools or filddler
Working from some time on a sails web application.
So far overcome all issues by hard reading, trial and error.
Recently had to install the app for a close beta test on the client's ec2 free trial instance where it works just fine in development mode.
The app is behind a nginx proxy which listens on the 80 port and redirects to http://server_IP:1337.
CORS and CSRF are enabled, allowOrigins and onlyAllowOrigins are set to the server IP, web domain and localhost in production.js and, security.js and sockets.js.
But when switching to production mode all API requests, except GET, give 403 forbidden.
Tried everything I could find on Google, it simply doesn't work on production but it completely works on development.
If anyone could share a shred of light on this will be greatly appreciated.
EDIT:
Running the app with debug silly, showed this:
A socket is being allowed to connect, but the session could not be loaded. Creating an empty, one-time session to use for the life of this socket connection.
This log often shows up because a client socket from a previous lift or another Sails app is trying to reconnect (e.g. from an open browser tab), but the session indicated by its cookie no longer exists-- because either this app is not currently using a persistent session store like Redis, or the session entry has been removed from the session store (e.g. by a scheduled job or because it expired naturally).
Details:
Error: Session could not be loaded.
at Immediate._onImmediate (/var/www/allscubashops.com/node_modules/sails/lib/hooks/session/index.js:543:42) at processImmediate (internal/timers.js:445:19)
Then I have deleted the old browser cookie and got this:
Could not fetch session, since connecting socket has no cookie in its handshake.
Generated a one-time-use cookie:
sails.sid=s%3APlHbdXvOZRo5yNlKPdFKkaPgVTNaNN8i.DwZzwHPhb1%2Fs9Am49lRxRTFjRqUzGO8UN90uC7rlLHs
and saved it on the socket handshake.
This means the socket started off with an empty session, i.e. (req.session === {})
That "anonymous" session will only last until the socket is disconnected. To work around this,
make sure the socket sends a cookie header or query param when it initially connects.
(This usually arises due to using a non-browser client such as a native iOS/Android app,
React Native, a Node.js script, or some other connected device. It can also arise when
attempting to connect a cross-origin socket in the browser, particularly for Safari users.
To work around this, either supply a cookie manually, or ignore this message and use an
approach other than sessions-- e.g. an auth token.)
Also no new cookie was set.
The apparent conclusion is that somehow in production mode something is wrong with setting the session.
EDIT 2:
The latest find is that if I run the app without nginx proxy, I do not have the forbidden API requests issue but I still have the one related to the session not being created.
I am sure the nginx proxy settins are OK but now I am thinking of implementing the redis way to store sessions instead of the default memory one and see what happens
EDIT 3:
I have implemented the Redis sessions which works both for dev and prod modes.
Still same situation, the ec2 instance without nginx proxy works in production mode while the same files (git replicated) on the ec2 instance with nginx proxy doesn't work in production mode (API requests 403 forbidden) but works great in development mode.
The X-CSRF token is sent, screenshot
The sails error message I get in production (besides the network 403 forbidden error for all requests except GET) is:
A socket is being allowed to connect, but the session could not be loaded. Creating an empty, one-time session to use for the life of this socket connection.
This log often shows up because a client socket from a previous lift or another Sails app is trying to reconnect (e.g. from an open browser tab), but the session indicated by its cookie no longer exists-- because either this app is not currently using a persistent session store like Redis, or the session entry has been removed from the session store (e.g. by a scheduled job or because it expired naturally).
Details:
Error: Session could not be loaded.
at /var/www/example.com/node_modules/sails/lib/hooks/session/index.js:543:42
at Command.callback (/var/www/example.com/node_modules/#sailshq/connect-redis/lib/connect-redis.js:148:25)
at normal_reply (/var/www/example.com/node_modules/machinepack-redis/node_modules/redis/index.js:714:21)
at RedisClient.return_reply (/var/www/example.com/node_modules/machinepack-redis/node_modules/redis/index.js:816:9)
at JavascriptRedisParser.returnReply (/var/www/example.com/node_modules/machinepack-redis/node_modules/redis/index.js:188:18)
at JavascriptRedisParser.execute (/var/www/example.com/node_modules/redis-parser/lib/parser.js:574:12)
at Socket. (/var/www/example.com/node_modules/machinepack-redis/node_modules/redis/index.js:267:27)
at Socket.emit (events.js:193:13)
at addChunk (_stream_readable.js:296:12)
at readableAddChunk (_stream_readable.js:277:11)
at Socket.Readable.push (_stream_readable.js:232:10)
at TCP.onStreamRead (internal/stream_base_commons.js:150:17)
Therefore I assume that the sockets connect but the session is not created.
Redis works OK, I see sessions in it for when in development.
Have you exposed the csrf endpoint and are you making a call to that endpoint first, to get a token, before making further requests? This tipped me up once.
I want to capture traffic from a host using HTTP, but I do not see a response coming back. If I close fiddler, my application runs as normal.
I see '-' in the Result section, where it should have been an HTTP response code. If I manually execute the request using Composer, I get a 200 response. Fiddler is able to capture traffic from all other web applications without issue.
I have installed Fiddler certificate. Troubleshooting Mode returns 200. The host does not use HTTPS, but I have enabled Capture HTTPS Connects anyways.
I am using Fiddler v5.0.20182
Some applications performs certificate pinning. Also web applications can perform certificate pinning e.g. via HTTP Public Key Pinning (HPKP). If you have ever used the web application in your browser without Fiddler, the web app public key has been downloaded and cached in the web-browser.
Afterwards the Fiddler root certificate is no longer accepted for that site/app even it it has been installed correctly. You should be able to identify such problematic connections in Fiddler if you only see a CONNECT request but no subsequent requests to the same domain.
To delete the HPKP in your web browser you should use a fresh profile or clear the complete browser cache. Afterwards only use it with activated Fiddler proxy and SSL decryption. As far as I know Fiddler will remove HPKP data from responses so that the web application should also work with Fiddler in between.
I think you should be able to uncheck the options for https, uncheck the boxes which appear checked here? Or you might be able to skip decryption by adding the host in the box below where it says Skip decryption for the following hosts
I'm using Eclipse to develop an app that consists of an Angular 2 front end and a Java REST back end.
For the front end, I'm using the Angular CLI plugin, which starts the app by issuing an ng serve command to the CLI. This command sets up an http server on port 4200.
For the back end, I'm using an in-company framework that launches in Jetty within Eclipse in port 8088.
While both these ports are configurable, by nature of the frameworks and plugins in use, they'll always be distinct.
Authentication works via an OAuth2 service that is also deployed to port 8088, as part of the framework. This service sets a cookie which certifies the browser session as authenticated. I have verified that this service works correctly by testing it against a Swagger instance of the REST API (also running in 8088 as part of the same framework).
The problem is that when the browser is aimed at the Angular 2 app on :4200, its internal REST API requests to :8088 aren't carrying the authentication cookie. Presumably, this is because of cross-site protection.
Is there any way for the app or the framework to tell the browser that these two "sites" are actually part of the same system?
Alternatively, if I have to configure the dev browser (Chrome) to work, I can live with that too. However, I've tried the --disable-web-security --user-data-dir recommendation, but the cookie still doesn't show up on the requests.
Lastly, I have Apache installed on the dev machine. If I can set up appropriate vhosts and use it as a proxy so that the browser thinks it's all the same, that would probably work too. It would just be a matter of intercepting all /swagger and /api requests and sending them to :8088, and all forwarding all other requests to :4200. However, I've been banging my head against mod_rewrite and mod_proxy and haven't been able to come up with anything that works.
I think what you're looking for is
withCredentials = true
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials