When I wanna set the proxy in my extension, I use chrome.proxy.settings.set()
Then I use the
chrome.webRequest.onAuthRequired.addListener(callbackFn, {urls: ['<all_urls>']}, ['blocking']);
const callbackFn = (details: any) => {
const username = 'someUser';
const password = 'somePass';
return {authCredentials: {username, password}};
}
But after 5mins I want to use another user creds. When I set proxy.settings.clear({}) - that's clear proxy and I have my default ip. After that I set proxy, set new onAuthRequired listener, but chrome saved somewhere my first creds, and I can't change it by onAuthRequired because chrome set my first creds to headers for proxy server.
How can I delete from chrome my creds that I have set before?
I think that chrome save connection with server. Because the proxy ask for creds only after chrome reopen.
How to close connection with proxy server (by chrome API)?
So I have found a solution of the problem.
onAuthRequired after server 407 response, get the creds and save it to cookie.
Then for every request browser add Authentication header with your creds from cookie.
This part of code remove creds cookies, and after new proxy connection the server will ask for a new creds.
let options = {};
const rootDomain = 'your.proxy.host'; // for example domain.com
options.origins = [];
options.origins.push("http://"+ rootDomain);
options.origins.push("https://"+ rootDomain);
let types = {"cookies": true};
chrome.browsingData.remove(options, types, function(){
// some code for callback function
});
For example if you have authentication in extension, you can add this code to logout function like in my application.
Related
I use node.js, express and express-ws that is based on ws
Express-ws allows to create express-like endpoints for websockets.
I am looking for a solution to authenticate users in websocket connections, based on a token. Since my ws server is based on an HTTP one
const wsHttpServer = http.createServer();
wsHttpServer.listen(5001);
const expressWs = require('express-ws')(app , wsHttpServer);
and since the ws connection is based on an HTTP one that gets upgraded to a ws, WHY I cannot pass a token in my ws that the express route checks, like any other one? My logic is, send the token, check it, if it is ok, proceed to upgrade to a ws connection. So, I can reuse the token-middleware solution that I have in my HTTP connections.
In node
My ws server
const wsHttpServer = http.createServer();
wsHttpServer.listen(5001);
const expressWs = require('express-ws')(app , wsHttpServer);
//set the route
app.use('/ws', require('./routes/wsroute'));
In that route, I would like to use the token.validate() middleware -that in HTTP connections, checks the Authorization header
router.ws('/user/:name/:id', token.validate(), (ws, req) => {
console.log('ws route data : ',vessel, req.params.name, req.params.id);
});
In my client
const socket = new WebSocket('ws://localhost',{
path: '/user/Nick/25/',
port: 5001, // default is 80
protocol : "echo-protocol", // websocket protocol name (default is none)
protocolVersion: 13, // websocket protocol version, default is 13
keepAlive: 60,
headers:{ some:'header', 'ultimate-question':42 } // websocket headers to be used e.g. for auth (default is none)
});
this errors Failed to construct 'WebSocket': The subprotocol '[object Object]' is invalid
I also tried
const socket = new WebSocket('ws://localhost:5001/user/Nick/25', ["Authorization", localStorage.getItem('quad_token')]);
I dont get any errors, but I dont know how to get the Authorization "header" in node
I could
just send const socket = new WebSocket(currentUrl); with some data and include a valid token in that data. But to check it, I have to allow the connection first. I dont want that, I would like to use a middleware solution that automatically checks a token and allows or not to continue.
Questions
Please help me understand:
1 Is it possible to use a token-based, middleware-based solution in ws?
2 How to set a header with a token in a ws connection?
3 How to get that token in node?
1) In my experience there is no available express.js middleware and the solution i found requires to listen to the upgrade event on your http server and blocking access to your socket connection before it reaches ws routes.
2) Your browser will not allow setting additional headers during websocket connection on the client side. It will send though the cookies so you can make use of express-session to authorize on your server first the user, a cookie will be set on the browser and that cookie will be sent over during the websocket connection.
3) You can do like in this answer Intercept (and potentially deny) web socket upgrade request Copying the code here from there for your own perusal.
**wsHttpServer**.on('upgrade', function (req, socket, head) {
var validationResult = validateCookie(req.headers.cookie);
if (validationResult) {
//...
} else {
socket.write('HTTP/1.1 401 Web Socket Protocol Handshake\r\n' +
'Upgrade: WebSocket\r\n' +
'Connection: Upgrade\r\n' +
'\r\n');
socket.close();
socket.destroy();
return;
}
//...
});
As outlined here, it seems that it is not possible for a standard browser websocket client to handle a http error response to an upgrade request. Thus what I ended up using was something like this:
HTTPserver.on('upgrade' (req, sock, head) => {
if (req.url === wsRoute) {
webSocketServer.handleUpgrade(req, sock, head, ws => {
const authenticated = validateToken(req.headers.cookie) // your authentication method
if (!authenticated) {
ws.close(1008, 'Unauthorized') // 1008: policy violation
return
}
webSocketServer.emit('connection', ws, req)
})
} else {
sock.destroy()
}
}
This way we accept the connection first before closing it with an appropriate code and reason, and the websocket client is able to process this close event as required.
On your client side, you should pass an array of strings instead of object, but you must set a header for your HTTP response with a key and value:
key : headeSec-WebSocket-Protocol
value : corresponding protocol used in front.
Here is a repo showing my latest progress, and here is my configuration. As it stands that repo now doesn't even authenticate with REST - although I think something is wrong with socket auth that needs to be looked at.
I configured feathers, was able to create a user REST-fully with Postman, and even get an auth token (I can post to /authenticate to get a token, and then verify that token - yay postman! yay REST api!).
But in the browser the story ain't so happy. I can use find to get data back, but authenticate just gives me errors.
In my googling I found this post and updated my client javascript to be this. I have also tried doing jwt auth with the token from postman, but that gives the same Missing Credentials error. Halp!
Code incoming...
app.js (only the configuration part to show order)
app.configure(configuration(path.join(__dirname, '..')))
.use(cors())
.use(helmet()) // best security practices
.use(compress())
.use(favicon(path.join(app.get('public'), 'favicon.ico')))
.use('/', feathers.static(app.get('public')))
.configure(socketio())
.configure(rest())
.configure(hooks())
.use(bodyParser.json())
.use(bodyParser.urlencoded({ extended: true }))
.configure(services) // pull in all services from services/index.js
.configure(middleware) // middleware from middleware/index.js
.hooks(appHooks)
Within services, I first add authentication, which is in its own file and that looks like this
authentication.js
const authentication = require('feathers-authentication');
const jwt = require('feathers-authentication-jwt');
const local = require('feathers-authentication-local');
const authManagement = require('feathers-authentication-management');
module.exports = function () {
const app = this;
const config = app.get('authentication');
// Set up authentication with the secret
app.configure(authentication(config));
app.configure(authManagement(config));
app.configure(jwt());
app.configure(local(config.local));
// The `authentication` service is used to create a JWT.
// The before `create` hook registers strategies that can be used
// to create a new valid JWT (e.g. local or oauth2)
app.service('authentication').hooks({
before: {
create: [
authentication.hooks.authenticate(config.strategies)
],
remove: [
authentication.hooks.authenticate('jwt')
]
}
});
};
index.html (mostly stripped, just showing relevant script)
let url = location.protocol + '//' + location.hostname +
(location.port
? ':' + location.port
: '');
const socket = io(url);
const feathersClient = feathers()
.configure(feathers.socketio(socket))
.configure(feathers.hooks())
.configure(feathers.authentication({ storage: window.localStorage }));
Here's a screen shot showing some requests in chrome debugger and postman.
When default.json is set to use 'username' as the usernameField it outputs my Windows username, 'Matt'. This is because feathers-configuration checks to see if a value is a part of the OS environment.
https://github.com/feathersjs/feathers-configuration/blob/master/src/index.js#L26
Workaround
Manually set this configuration in authentication.js, for example:
// Set up authentication with the secret
const localConfig = {
'entity': 'users',
'service': 'users',
'usernameField': 'username',
'passwordField': 'password'
};
app.configure(authentication(config));
app.configure(local(localConfig));
I am using SockJS on Express server. Is there any way to get the associate HTTP session ID of the client?
I see there is a way to do it for raw web socket and Socket.io, but I am struggling to find how to do it for SockJS.
This is how my server looks like. I want a similar handler to fetch session ID:
var sockjs_echo = sockjs.createServer(sockjs_opts);
sockjs_echo.on('connection', function(conn) {
conn.on('data', function(message) {
conn.write(message);
});
});
This is a "hack", but it works for me:
sockjs_echo.on('connection', function(conn) {
var cookieHeader = conn._session.recv.ws._stream._readableState.pipes._driver._request.headers.cookie
var cookies = {}
cookieHeader.split(';').forEach(function( cookie ) {
var parts = cookie.split('=');
cookies[parts.shift().trim()] = decodeURI(parts.join('='));
});
conn.on('data', function(message) {
conn.write(message);
});
});
'cookies' variable (example):
{
"dev_cookie": "1mimec6rbcolp0ujkcbqq9pdq4uoa5v0p8a284v32tmd4q3k0qi9p4vjteoifdn9b0lsm238fghf974o9jfehfuhvm3ltrgq02ad6k0",
"session_cookie": "s%3AjkKYPKFFT8r60rXUsVYISoOF17o49GUl.pbpu6T1%2BcdrIu5uQPRxZUYOrl5GnC179GaI5pWyR7SA",
"other_cookie": "s%3AzRMiC3fjo4gxTXX1p2XSi_C_EydIa358.KAdP1gwtZBVfcbkmwi%2B3pa0L1pbOCzQ3lHnNEyFvvHc"
}
Thanks so much for asking this question, #darwinbaisa, and for the answer, c-toesca. This came after days of searching.
For XHR streaming, the cookies are at: conn._session.recv.request.headers.cookie.
The only other way I could think of doing this was to make the express session cookie httpOnly: false, thus exposing it to javascript and, of course, the possibility of hacking, then pass it back as a prefix to any message from the SockJS javascript client to the node server.
Or to assign the ID to a javascript variable as I dynamically wrote a web page response, so that javascript would have access to the variable, and again could return it to the server. But again, this would have exposed the ID, and even if the ID was hashed or encrypted, it could still be used in a malicious call to the server from javascript.
Things like this are made a lot easier in the node WS library, but I need a fallback from that for websocket-challenged browsers.
We're using Hapi JS for our rest server. We store the authentication tokens for the users on Redis. Now, if for some reason node loses connection with Redis, we need to return 401 Authorization failed error to all the clients from all the routes so the clients can logout automatically.
So, is there a way to return 401 from all routes without changing the code in the route handler functions?
You can make use of the Hapi server extension event 'onRequest'.
var hapi = require('hapi');
var Boom = require('boom');
var server = new hapi.Server();
//Configure your server
//Add an extension point
server.ext('onRequest', function (request, reply) {
var status;
//Check status of redis instance
if (status) {
//Redis is running, continue to handler
return reply.continue();
} else {
//Redis is down, reply with error
return reply(Boom.unauthorized('Auth server is down'));
}
});
This is probably not how you will verify the status your redis instance, but I hope you get the point.
One can look up various other extension points here.
You should do this in the auth plugin used by your app. Take a look at the hapi-auth-basic implementation: https://github.com/hapijs/hapi-auth-basic/blob/master/lib/index.js
If you look in the scheme you must define an authenticate method which takes the request and reply. This is where you should check redis for an auth token. If the connection is not available you should
return reply(Boom.unauthorized('Authorization failed', 'Basic'));
Hope this helps.
I'm trying to test an app's socket.io which uses passport.socketio to authenticate the socket connection
var socket = require('socket.io-client')('http://localhost:' + app.PORT);
This does not work because there's no accompanying cookie.
Even if I get the cookie from a persisted superagent session
var cookie;
var agent = request.agent(app);
agent.post('/login').send('credentials').end(function(err, res) {
cookie = res.req._headers.cookie;
});
where/how do I use it ?
I found that there are already quite a few requests for socket.io-client to add cookie support
http://github.com/LearnBoost/socket.io-client/issues/450
http://github.com/LearnBoost/socket.io-client/pull/439
http://github.com/LearnBoost/socket.io-client/issues/344
but I don't see them going anywhere.
Is there any other solution to use persistent cookie session with socket while testing?
Cookie data could be passed using querystring
agent.post('/login').send('credentials').end(function(err, res) {
cookie = res.req._headers.cookie.replace(/=/g, '%3D'); //escape '='
});
socket = require('socket.io-client')('http://localhost' + '/?cookie=' + cookie);
It becomes available in the server socket
io.set('authorization', function(handshakeData, callback){
handshakeData._query.cookie;
});
And so it can be used to perform authorization. Since I was using passport.socketio, it plays nicely with a little change to check this query string instead of headers.