How to extract request http headers from a request using NodeJS connect - node.js
I'd like to get the "Host" header of a request made using Node JS's connect library bundle. My code looks like:
var app = connect()
.use(connect.logger('dev'))
.use(connect.static('public'))
.use(function(req, res){
var host = req.???
})
.listen(3000);
The documentation for connect is here but I don't see anything detailing the API of the req object in the above code. http://www.senchalabs.org/connect/
Edit: Note a successful answer must point to the documentation (I need this to verify which version provided the API I'm looking for).
If you use Express 4.x, you can use the req.get(headerName) method as described in Express 4.x API Reference
To see a list of HTTP request headers, you can use :
console.log(JSON.stringify(req.headers));
to return a list in JSON format.
{
"host":"localhost:8081",
"connection":"keep-alive",
"cache-control":"max-age=0",
"accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
"upgrade-insecure-requests":"1",
"user-agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.107 Safari/537.36",
"accept-encoding":"gzip, deflate, sdch",
"accept-language":"en-US,en;q=0.8,et;q=0.6"
}
Check output of console.log(req) or console.log(req.headers);
var host = req.headers['host'];
The headers are stored in a JavaScript object, with the header strings as object keys.
Likewise, the user-agent header could be obtained with
var userAgent = req.headers['user-agent'];
logger.info({headers:req.headers})
Output;
"headers":{"authorization":"Basic bmluYWQ6bmluYWQ=","content-
type":"application/json","user-
agent":"PostmanRuntime/7.26.8","accept":"*/*","postman-token":"36e0d84a-
55be-4661-bb1e-1f04d9499574","host":"localhost:9012","accept-
encoding":"gzip, deflate, br","connection":"keep-alive","content-
length":"198"}
In express, we can use request.headers['header-name'], For example if you have set up a Bearer token in authorization header and want to retrieve the token, then you should write req.headers['authorization'], and you will get the string containing 'Bearer tokenString'.
Related
Node Js(Express) - POST req.body is empty (unusual)
I didn't realize how common and tricky this problem is. I have spent many hour reviewing all the previous situations and answers. Needless to say, none apply.
I am making a httpClient POST call from Angular 5 to a nodejs/express url. The application makes many of these calls and all works except this one:
Angular component
this.ezzy.post(this.config.api.createConnectAccount, this.AuthCode, true, true, true)
.subscribe((data) => {
if (data.code === '0') {
angular http call
ngOnInit() {
........
createConnectAccount(url, body, loadingIcon, withCredentials, showErrorToast) {
console.log(`CREATE CONNECT ACCOUNT....${url}...${JSON.stringify(body)}`);
const headers = this.ezzy.preAjax(loadingIcon, withCredentials);
return this.http.post(url, body, { withCredentials, headers })
.map((res) => this.ezzy.postAjax(res, showErrorToast))
.catch((err) => this.ezzy.handleError(err));
}
I can confirm that both the url and the authCode/body are correct and present up tho this point.
router.post (Nodejs)
router.post('/users/createConnectAccount', async(req, res, next) => {
// console.log (`REQ BODY FROM PAYOUT DASH: ${JSON.stringify(req)}`);
console.log(`ENTER CREATE CONNECT ACCOUNT...code......${req.body.code}`);
console.log(`ENTER CREATE CONNECT ACCOUNT..body......${JSON.stringify(req.body)}`);
console.log(`REQ HEADERS: ${JSON.stringify(req.headers)}`);
Here are the differences with other similar calls:
1. The angular component was activated from an external call to its endpoint (localhost:3000/dealer?code='1234'. The code was retrieved succesfully in the component's constructor and assigned to authCode.
2. The angular http call orginated inside the ngOnInit. I am trying to get some info and update the db before rendering the component page.
I am using
app.use(json());
app.use(urlencoded({
extended: true
}));
and a console.log of the req.header before the call is this:
ENTER CREATE CONNECT ACCOUNT...code......undefined
ENTER CREATE CONNECT ACCOUNT..body......{}
REQ HEADERS: {"host":"localhost:3000","connection":"keep-alive","content-length":"35","accept":"application/json,
text/plain, */*","sec-fetch-dest":"empty","user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36","content-type":"text/plain","origin":"http://localhost:3000","sec-fetch-site":"same-origin","sec-fetch-mode":"cors","referer":"http://localhost:3000/payout-dashboard?code=ac_H5nP4MUbEbp94K13jkA5h1DRG6f6pgOn&state=2lt8v9le8a5","accept-encoding":"gzip, deflate, br","accept-language":"en-US,en;q=0.9","cookie":"connect.sid=s%3AsWLHYTY02P2EvYZy1FIVQzZLC6M0vR5p.GnU%2BU20RcjPYeG3lAUEDV9q1vmLceBPAfEE488ej5M4; _ga=GA1.1.695338957.1586021131; _gid=GA1.1.1793736642.1586291730; PDToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJlbWFpbCI6InNlYWthaG1haWxAZ21haWwuY29tIiwibmlja25hbWUiOiIiLCJjYXRlZ29yeSI6IiIsImlhdCI6MTU4NjgyMDYyMSwiZXhwIjoxNjE4MzU2NjIxfQ.09gx1F_YJPxAs7BiiYToetdJhjd5DsUUkdoo3leFscU; io=yysQe40_plBblVuSAAAA"}
If you notice that the content-type is:
"content-type":"text/plain"
and the accepted is:
"accept":"application/json,
text/plain, */*"
and the code is present:
code=ac_H5nP4MUbEbp94K13jkA5h1DRG6f6pgOn&state=2lt8v9le8a5"
YET...I get empty req.body.
BTW....it works from postman
ENTER CREATE CONNECT ACCOUNT...code......ac_H5ikfuYleQromTeP5LnHGEmfEWaYD3he
ENTER CREATE CONNECT ACCOUNT..body......{"code":"ac_H5ikfuYleQromTeP5LnHGEmfEWaYD3he"}
REQ HEADERS: {"user-agent":"PostmanRuntime/7.24.1",
"accept":"*/*","postman-token":"0d5faea6-4684-408e-9235-c5e14b306918",
"host":"localhost:3000",
"accept-encoding":"gzip,
deflate, br","connection":"keep-alive",
"content-type":"application/x-www-form-urlencoded",
"content-length":"40","cookie":"connect.sid=s%3ASahJY3VqXVjTjXF1X-SlU_9Shexa59Tm.Q0SRM1h%2FxJnoEnjS3u3I3x%2F%2FnLs%2FLzyiHGoJNuo0U7M"}
Sorry to be so long...but I am baffled
The urlencoded express middleware only parses the body when the Content-Type of the request matches the type option. By default, the type option is application/x-www-form-urlencoded. Either set the Content-Type of your request from text/plain to application/x-www-form-urlencoded, or pass {"type": "text/plain"} to urlencoded(...) to overwrite the default behavior.
Delete API not working in nodejs 10.15.3. Getting as "400 Bad Request". It is working in nodejs 8.15.3. What is the fix for node 10?
There is a delete API link as api/private/v1/configuration/config and sending a body as [{"name": "public:space", "key": "keyvalue"}] with DELETE.
The headers used is
Host: dev.corp:8000
Connection: keep-alive
Accept: application/json, text/plain, */*
X-CSRF-Token: ae63017624d7315328a52544f923995f
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
X-Requested-With: XMLHttpRequest
Referer: http://dev.corp:8000/feedback-plugin/
Accept-Encoding: gzip, deflate
Accept-Language: en,de;q=0.9,fr;q=0.8,ko;q=0.7,en-IN;q=0.6,zh-TW;q=0.5,zh;q=0.4,en-US;q=0.3,ja;q=0.2,zh-CN;q=0.1,kn;q=0.1,fr-CA;q=0.1,la;q=0.1
Cookie: splashCookieConsentId=e011cd34-b3b2-44c9-bb48-0cb1da07626a; _swa_v_ses.1a649b30-efbc-d34c-9f20-00ff0ace414e.02a5=*; X-CSRF-Token=ae63017624d7315328a52544f923995f; _pk_id.1a649b30-efbc-d34c-9f20-00ff0ace414e.02a5=a3c49cd9ca99810d.1560162024.0.1560241425..; _swa_v_id.1a649b30-efbc-d34c-9f20-00ff0ace414e.02a5=c13ce6e4611014d2.1560162025.5.1560241425.1560232562.; buildSessionId=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiNWNmZTJlZTA1MDFlZTNmNTRkNjUwMTQyIiwic3ViIjoiYXZpbmFzaC5rc2hlZXJhc2FnYXJhQHNhcC5jb20iLCJlbWFpbCI6ImF2aW5hc2gua3NoZWVyYXNhZ2FyYUBzYXAuY29tIiwibG9jYWxlIjoiZW4tVVMiLCJuYW1lIjoiQXZpbmFzaCBSIEsiLCJzZXNzaW9uIjoiNDY0NDEyYTI5ODZmYTdiNzZmMzM1MjE1MzY4MTBjNDciLCJzZXNzaW9uX3N0YXJ0IjoxNTYwMjQxNDIxODExLCJvcmciOlsic2FwLXNwbGFzaC1jaS5tby5zYXAuY29ycDo4MDAwIl0sInhzcmYiOiJhZTYzMDE3NjI0ZDczMTUzMjhhNTI1NDRmOTIzOTk1ZiIsInhzcmZDb29raWUiOnRydWUsImludGVyYWN0aXZlIjp0cnVlLCJ0ZW5hbnQiOiJzYXAtc3BsYXNoLWNpLm1vLnNhcC5jb3JwOjgwMDAiLCJpYXQiOjE1NjAyNDE0MzIsImV4cCI6MTU2MDI0MzIzMn0.fInmr0dmgYobYI4R01zTanmdM3NnX2fmg2uQ1-j8Iko; userSessionId=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZXNzaW9uX3N0YXJ0IjoxNTYwMjQxNDIxOTYyLCJpYXQiOjE1NjAyNDE0MzIsImV4cCI6MTU2MDI0MzIzMn0.ccpf-BBB8u4JZneg0GDfearz0SsHDsUSo9zlelI6u7A
Content-Type:application/json
Tried to add body parser
app.use('/configuration/config', [bodyParser.urlencoded({extended: false}), api.token]);
and also tried using Transfer-Encoding: chunked in header, but no use.
getting 400 Bad Request always in delete API for node js 10.
How this can be solved?
You can do:
// Add this module to your package.json & do npm install
const morgan = require('morgan');
// Will log calls on the express side
app.use(morgan('dev'));
// No need to do this every call, do it once
app.use(bodyParser.urlencoded({extended: false}));
// Handles the DELETE route specifically
app.delete('/configuration/config', api.token, (req, res, next) => {
console.log("/configuration/config called without problems");
// TODO: BODY of function
});
If there is a problem, it's likely in the code of api.token and what it is meant to achieve. Also, you need to make sure that the app listens at the api/private/v1 endpoint.
Side-note: Content-Type:application/json, maybe add a space after : ?
--max-http-header-size=80000 it went from 80k in 8.x to 8k in 10.x
TOO_MANY_REDIRECTS error when iFraming Kibana dashboard using cookies
I'm attempting to embed password protected Kibana dashboards inside an iFrame to my Node powered Express application, based on information in this thread. Kibana is protected using X-Pack and requires users to login in order to see their visualised data.
This currently requires the user to log in twice, once to login into the application and again to access Kibana dashboards, which is not the goal.
Following information in this thread, I implemented some code that makes a pre-flight POST request to https://elk-stack.my.domain:5601/api/security/v1/login to obtain a cookie 🍪
This client side request...
function preFlightKibanaAuth () {
...
$.ajax({
type: 'POST',
url: '/kibana-auth',
datatype: 'json',
success: function (response) {
if (response && response.authenticated) {
$('iframe#kibana-dashboard').prop('src', 'https://elk-stack.my.domain:5601/s/spacename/app/kibana#/dashboards?_g=()')
}
},
error: function (err) {
console.log(err)
}
})
}
Is routed to this route...
router
.route('/kibana-auth')
.post((req, res, next) => {
...
if (authorised) {
...
authenticateKibana(req)
.then(cookie => {
if (cookie && cookie.name && cookie.value) {
res.set('Set-Cookie', `${cookie.name}=${cookie.value}; Domain=my.domain; Path=/; Secure; HttpOnly`)
res.send({ 'authenticated': true })
} else {
res.send({ 'authenticated': false })
}
})
.catch((err) => {
logger.error(err)
res.send({ 'authenticated': false })
})
}
...
})
Which makes it's way to this function, where the cookie is actually obtained and parsed...
authenticateKibana () {
return new Promise((resolve, reject) => {
...
request({
method: 'POST',
uri: `https://elk-stack.my.domain:5601/api/security/v1/login`,
headers: {
'kibana-version': '6.5.4',
'kibana-xsrf': 'xsrftoken',
},
type: 'JSON',
form: {
password: 'validPassword',
username: 'validUsername'
}
}, function (error, res, body) {
if (!error) {
let cookies = cookieParser.parse(res)
cookies.forEach(function (cookie) {
if (cookie.name.startsWith('kibana')) {
// Got Kibana Cookie
return resolve(cookie)
}
})
}
...
})
})
}
This works great and I can successfully authenticate with Kibana, obtain the cookie and set in the clients browser (see below screenshot).
The issue I'm seeing is when the src of the iFrame is updated in the success callback of the preFlightKibanaAuth() request. I can see the authenticated Kibana dashboard load in briefly (so the cookie is allowing the client to view their authenticated dashboards), however, I then see multiple GET requests to /login?next=%2Fs%2Fspacename%2Fapp%2Fkibana that results in a TOO_MANY_REDIRECTS error.
I've found the below comment in the GitHub issues page, which I think maybe the issue I'm having in some way because I'm seeing this in the logs (see bottom): "message":"Found 2 auth sessions when we were only expecting 1.". I just can't figure it out!
Usually what causes this is having multiple cookies for the same
"domain" and "name", but with different values for "path". If you open
the developer tools in Chrome, then click on the Application tab, then
expand the Cookies section, and click on the domain, do you have
multiple cookies with the name "sid"? If so, you can fix this issue by
clearing all of them.
I changed the cookie name from "sid" to "kibana" but don't have two of them visible in Applications tab, just the one I set following the call to /kibana-auth.
The iFrame then loads in the https://elk-stack.my.domain:5601/s/spacename/app/kibana#/dashboards?_g=() and the issue arises. Clearing my cookies just resulted in fetching and setting another one (if we don't already have one), which is what is required, so this didn't solve the problem.
When I send the Set-Cookie header back to the client, I am setting the Domain to the main domain: my.domain, which ends up as .my.domain. The Kibana instance is on a subdomain: elk-stack.my.domain and if I login to the Kibana front end, I can see that the Domain of the cookie it returns is set to elk-stack.my.domain. I'm not sure that should matter though.
Can anyone please shed any light on this or point me in the direction?
Thanks in advance
Here's a glimpse at the logging info from /var/log/kibana/kibana.stdout when a request is made. There's a bit of junk in there still but you can still see what's happening.
{"type":"log","#timestamp":"2019-02-12T19:47:44Z","tags":["debug","security","basic"],"pid":7857,"message":"Trying to authenticate user request to /api/security/v1/login."}
{"type":"log","#timestamp":"2019-02-12T19:47:44Z","tags":["debug","security","basic"],"pid":7857,"message":"Trying to authenticate via header."}
{"type":"log","#timestamp":"2019-02-12T19:47:44Z","tags":["debug","security","basic"],"pid":7857,"message":"Request has been authenticated via header."}
{"type":"response","#timestamp":"2019-02-12T19:47:44Z","tags":[],"pid":7857,"method":"post","statusCode":204,"req":{"url":"/api/security/v1/login","method":"post","headers":{"kibana-version":"6.5.4","kbn-xsrf":"6.5.4","host":"10.30.10.30:5601","content-type":"application/
x-www-form-urlencoded","content-length":"35","connection":"close"},"remoteAddress":"192.168.56.102","userAgent":"192.168.56.102"},"res":{"statusCode":204,"responseTime":109,"contentLength":9},"message":"POST /api/security/v1/login 204 109ms - 9.0B"}
{"type":"log","#timestamp":"2019-02-12T19:47:44Z","tags":["debug","legacy","proxy"],"pid":7857,"message":"Event is being forwarded: connection"}
{"type":"log","#timestamp":"2019-02-12T19:47:44Z","tags":["trace","legacy","service"],"pid":7857,"message":"Request will be handled by proxy GET:/s/spacename/app/kibana."}
{"type":"log","#timestamp":"2019-02-12T19:47:44Z","tags":["warning","security","auth","session"],"pid":7857,"message":"Found 2 auth sessions when we were only expecting 1."}
{"type":"log","#timestamp":"2019-02-12T19:47:44Z","tags":["debug","security","basic"],"pid":7857,"message":"Trying to authenticate user request to /app/kibana."}
{"type":"log","#timestamp":"2019-02-12T19:47:44Z","tags":["debug","security","basic"],"pid":7857,"message":"Trying to authenticate via header."}
{"type":"log","#timestamp":"2019-02-12T19:47:44Z","tags":["debug","security","basic"],"pid":7857,"message":"Authorization header is not presented."}
{"type":"response","#timestamp":"2019-02-12T19:47:44Z","tags":[],"pid":7857,"method":"get","statusCode":302,"req":{"url":"/app/kibana","method":"get","headers":{"host":"elk-stack.my.domain:5601","connection":"keep-alive","upgrade-insecure-requests":"1","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8","referer":"https://local.local.my.domain/fortigate/reporting/dashboard","accept-encoding":"gzip, deflate, br","accept-language":"en-GB,en;q=0.9,en-US;q=0.8,la;q=0.7,fr;q=0.6"},"remoteAddress":"192.168.56.102","userAgent":"192.168.56.102","referer":"https://local.local.my.domain/fortigate/reporting/dashboard"},"res":{"statusCode":302,"responseTime":3,"contentLength":9},"message":"GET /app/kibana 302 3ms - 9.0B"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","legacy","proxy"],"pid":7857,"message":"Event is being forwarded: connection"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","legacy","proxy"],"pid":7857,"message":"\"getConnections\" has been called."}
{"type":"ops","#timestamp":"2019-02-12T19:47:45Z","tags":[],"pid":7857,"os":{"load":[0.2568359375,0.31640625,0.3173828125],"mem":{"total":33567580160,"free":346796032},"uptime":1585351},"proc":{"uptime":33636.577,"mem":{"rss":322772992,"heapTotal":225566720,"heapUsed":184707176,"external":2052484},"delay":6.417333126068115},"load":{"requests":{"5601":{"total":2,"disconnects":0,"statusCodes":{"204":1,"302":1}}},"concurrents":{"5601":1},"responseTimes":{"5601":{"avg":56,"max":109}},"sockets":{"http":{"total":0},"https":{"total":0}}},"message":"memory: 176.2MB uptime: 9:20:37 load: [0.26 0.32 0.32] delay: 6.417"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","monitoring-ui","kibana-monitoring"],"pid":7857,"message":"Received Kibana Ops event data"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","monitoring-ui","kibana-monitoring"],"pid":7857,"message":"Received Kibana Ops event data"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["trace","legacy","service"],"pid":7857,"message":"Request will be handled by proxy GET:/login?next=%2Fs%2Fspacename%2Fapp%2Fkibana."}
{"type":"response","#timestamp":"2019-02-12T19:47:45Z","tags":[],"pid":7857,"method":"get","statusCode":302,"req":{"url":"/login?next=%2Fs%2Fspacename%2Fapp%2Fkibana","method":"get","headers":{"host":"elk-stack.my.domain:5601","connection":"keep-alive","upgrade-insecure-requests":"1","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8","referer":"https://local.local.my.domain/fortigate/reporting/dashboard","accept-encoding":"gzip, deflate, br","accept-language":"en-GB,en;q=0.9,en-US;q=0.8,la;q=0.7,fr;q=0.6"},"remoteAddress":"192.168.56.102","userAgent":"192.168.56.102","referer":"https://local.local.my.domain/fortigate/reporting/dashboard"},"res":{"statusCode":302,"responseTime":2,"contentLength":9},"message":"GET /login?next=%2Fs%2Fspacename%2Fapp%2Fkibana 302 2ms - 9.0B"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","legacy","proxy"],"pid":7857,"message":"Event is being forwarded: connection"}
The below then repeats over and over...
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["trace","legacy","service"],"pid":7857,"message":"Request will be handled by proxy GET:/s/spacename/app/kibana."}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["warning","security","auth","session"],"pid":7857,"message":"Found 2 auth sessions when we were only expecting 1."}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","security","basic"],"pid":7857,"message":"Trying to authenticate user request to /app/kibana."}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","security","basic"],"pid":7857,"message":"Trying to authenticate via header."}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","security","basic"],"pid":7857,"message":"Authorization header is not presented."}
{"type":"response","#timestamp":"2019-02-12T19:47:45Z","tags":[],"pid":7857,"method":"get","statusCode":302,"req":{"url":"/app/kibana","method":"get","headers":{"host":"elk-stack.my.domain:5601","connection":"keep-alive","upgrade-insecure-requests":"1","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8","referer":"https://local.local.my.domain/fortigate/reporting/dashboard","accept-encoding":"gzip, deflate, br","accept-language":"en-GB,en;q=0.9,en-US;q=0.8,la;q=0.7,fr;q=0.6"},"remoteAddress":"192.168.56.102","userAgent":"192.168.56.102","referer":"https://local.local.my.domain/fortigate/reporting/dashboard"},"res":{"statusCode":302,"responseTime":2,"contentLength":9},"message":"GET /app/kibana 302 2ms - 9.0B"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","legacy","proxy"],"pid":7857,"message":"Event is being forwarded: connection"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["trace","legacy","service"],"pid":7857,"message":"Request will be handled by proxy GET:/login?next=%2Fs%2Fspacename%2Fapp%2Fkibana."}
{"type":"response","#timestamp":"2019-02-12T19:47:45Z","tags":[],"pid":7857,"method":"get","statusCode":302,"req":{"url":"/login?next=%2Fs%2Fspacename%2Fapp%2Fkibana","method":"get","headers":{"host":"elk-stack.my.domain:5601","connection":"keep-alive","upgrade-insecure-requests":"1","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8","referer":"https://local.local.my.domain/fortigate/reporting/dashboard","accept-encoding":"gzip, deflate, br","accept-language":"en-GB,en;q=0.9,en-US;q=0.8,la;q=0.7,fr;q=0.6"},"remoteAddress":"192.168.56.102","userAgent":"192.168.56.102","referer":"https://local.local.my.domain/fortigate/reporting/dashboard"},"res":{"statusCode":302,"responseTime":2,"contentLength":9},"message":"GET /login?next=%2Fs%2Fspacename%2Fapp%2Fkibana 302 2ms - 9.0B"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","legacy","proxy"],"pid":7857,"message":"Event is being forwarded: connection"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["plugin","debug"],"pid":7857,"message":"Checking Elasticsearch version"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["trace","legacy","service"],"pid":7857,"message":"Request will be handled by proxy GET:/s/spacename/app/kibana."}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["warning","security","auth","session"],"pid":7857,"message":"Found 2 auth sessions when we were only expecting 1."}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","security","basic"],"pid":7857,"message":"Trying to authenticate user request to /app/kibana."}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","security","basic"],"pid":7857,"message":"Trying to authenticate via header."}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","security","basic"],"pid":7857,"message":"Authorization header is not presented."}
{"type":"response","#timestamp":"2019-02-12T19:47:45Z","tags":[],"pid":7857,"method":"get","statusCode":302,"req":{"url":"/app/kibana","method":"get","headers":{"host":"elk-stack.my.domain:5601","connection":"keep-alive","upgrade-insecure-requests":"1","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8","referer":"https://local.local.my.domain/fortigate/reporting/dashboard","accept-encoding":"gzip, deflate, br","accept-language":"en-GB,en;q=0.9,en-US;q=0.8,la;q=0.7,fr;q=0.6"},"remoteAddress":"192.168.56.102","userAgent":"192.168.56.102","referer":"https://local.local.my.domain/fortigate/reporting/dashboard"},"res":{"statusCode":302,"responseTime":2,"contentLength":9},"message":"GET /app/kibana 302 2ms - 9.0B"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","legacy","proxy"],"pid":7857,"message":"Event is being forwarded: connection"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["trace","legacy","service"],"pid":7857,"message":"Request will be handled by proxy GET:/login?next=%2Fs%2Fspacename%2Fapp%2Fkibana."}
{"type":"response","#timestamp":"2019-02-12T19:47:45Z","tags":[],"pid":7857,"method":"get","statusCode":302,"req":{"url":"/login?next=%2Fs%2Fspacename%2Fapp%2Fkibana","method":"get","headers":{"host":"elk-stack.my.domain:5601","connection":"keep-alive","upgrade-insecure-requests":"1","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8","referer":"https://local.local.my.domain/fortigate/reporting/dashboard","accept-encoding":"gzip, deflate, br","accept-language":"en-GB,en;q=0.9,en-US;q=0.8,la;q=0.7,fr;q=0.6"},"remoteAddress":"192.168.56.102","userAgent":"192.168.56.102","referer":"https://local.local.my.domain/fortigate/reporting/dashboard"},"res":{"statusCode":302,"responseTime":2,"contentLength":9},"message":"GET /login?next=%2Fs%2Fspacename%2Fapp%2Fkibana 302 2ms - 9.0B"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["debug","legacy","proxy"],"pid":7857,"message":"Event is being forwarded: connection"}
{"type":"log","#timestamp":"2019-02-12T19:47:45Z","tags":["plugin","debug"],"pid":7857,"message":"Checking Elasticsearch version"}
Kibana Version: 6.5.4
Elasticsearch: 6.5.4
At first, I thought this all turned out to be a mismatch in the Cookie attributes, alas, it wasn't! Received some info from the Elastic team... The cookie which Kibana replies with generally sets the httpOnly flag, and the secure flag (when hosted over https), in addition to the domain. If any of the settings differ for the cookie which you're trying to force Kibana to use, you'll see 2 cookies being submitted and behaviour similar to what you're seeing. Thought I was setting the cookie with different attributes, but wasn't... ended up using a plugin to get this off the ground: https://readonlyrest.com/
using nodejs, express and basic auth how do i get username and password
I am using nodejs, express
A third party that will be calling my api will be using basic auth in the format of http://{username}:{password}#yourdomain.com/
I have tried
var auth = require('basic-auth')
app.use(function(req, res, next) {
var credentials = auth(req)
if (req.headers.authorization) {
console.log("found headers");
}
}
But this only works if the basic auth is passed in the header.
I can not seem to get the username and password from the URL(which is the only way this external party can call my api)
I then tried as suggested use url
here is what i am seeing now when i do a POST to
http://myusername:mypassword#localhost:4050/api/callback
var express = require('express');
var http = require('http');
var url = require('url');
var app = express();
app.use(function(req, res, next) {
console.log("req.protocol=",req.protocol);
console.log("req.get('host')=",req.get('host'));
console.log("req.originalUrl=",req.originalUrl);
}
http.createServer(app).listen(config.port, function () {
console.log("HTTP BandWidth listening on port " + config.port);
});
My console looks like
req.protocol= http
req.get('host')= localhost:4050
req.originalUrl=/api/callback
if i dump the entire req obj i do not see myusername or mypassword
i must be missing something obvious
Thanks
Randy
You should be able to use the built-in url package in Node.
https://nodejs.org/dist/latest-v6.x/docs/api/url.html#url_urlobject_auth
const url = require('url');
app.use(function(req, res, next) {
const urlObj = url.parse(req.protocol + '://' + req.get('host') + req.originalUrl);
console.log('Auth info: ' + urlObj.auth);
}
Hope this helps!
EDIT: Well, I take that back. It looks like the use of username and password in the URI has been deprecated, and browsers may just be ignoring that information. See RFC 3986:
3.2.1. User Information
The userinfo subcomponent may consist of a user name and,
optionally, scheme-specific information about how to gain
authorization to access the resource. The user information, if
present, is followed by a commercial at-sign ("#") that delimits it
from the host.
userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
Use of the format "user:password" in the userinfo field is
deprecated. Applications should not render as clear text any data
after the first colon (":") character found within a userinfo
subcomponent unless the data after the colon is the empty string
(indicating no password). Applications may choose to ignore or
reject such data when it is received as part of a reference and
should reject the storage of such data in unencrypted form. The
passing of authentication information in clear text has proven to be
a security risk in almost every case where it has been used.
And...
7.5. Sensitive Information
URI producers should not provide a URI that contains a username or
password that is intended to be secret. URIs are frequently
displayed by browsers, stored in clear text bookmarks, and logged by
user agent history and intermediary applications (proxies). A
password appearing within the userinfo component is deprecated and
should be considered an error (or simply ignored) except in those
rare cases where the 'password' parameter is intended to be public.
I added the bold and italics...
I tried this using the developer tools in Chrome and got the following:
General
Request URL:http://foobar:password#localhost:8888/test
Request Method:GET
Status Code:200 OK
Remote Address:127.0.0.1:8888
Response Headers
Connection:keep-alive
Content-Length:19
Content-Type:application/json; charset=utf-8
Date:Thu, 08 Dec 2016 03:52:35 GMT
ETag:W/"13-uNGID+rxNJ6jDZKj/wrpcA"
Request Headers
GET /test HTTP/1.1
Host: localhost:8888
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
So, it doesn't even look like the username and password info is being passed along by Chrome. Unfortunately, I think you're out of luck if you're trying to use this schema. You may have to set the authorization headers, set your own custom headers (which is what I have done in the past), or pass your credentials in the query string.
Making a Post request to Github API for creating issue is not working
I have been trying to make this post request to the github api for the last couple of days, but unfortunately the response is coming back as "bad message"
here is the piece of code we are sending in the post request using https request in node -
This is the post data
var issueData = JSON.stringify({
"title":title,
"body":comment
});
This is the options file
var options = {
host: 'api.github.com',
path: '/repos/sohilpandya/katasohil/issues?access_token='+sessions.token,
headers: {
'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0',
},
method: 'POST'
};
This is the https request
var requestaddIssue = https.request(options, function(responseFromIssues){
responseFromIssues.setEncoding('utf8');
responseFromIssues.on('data', function(chunk){
console.log('>>>>chunk>>>>>',chunk);
issueBody += chunk;
});
responseFromIssues.on('end',function(issueBody){
console.log(issueBody);
});
});
requestaddIssue.write(issueData);
requestaddIssue.end();
I have tried another approach where the authentication token for the user is in the header as
'Authentication': 'OAuth '+ sessions.token (where we are storing token inside sessions)
But the chunk response always seems to come back with the following in the console log.
{
"message": "Not Found",
"documentation_url": "https://developer.github.com/v3/issues/#create-an-issue"
}
I have tried the same in apigee and it seems to work ok and returns to correct response. Hoping someone can find the minor error in the code above that is causing this bad message error.
Except the issueBody variable is not defined in the snippets you posted, the code is correct. I tried it using a personal access token. The error you get appears because you need to add a scope with power to open issues. I tried the repo and public_repo scopes and they are both working. Note that repo has access to private repositories. Here you can see the list of scopes. If you're using OAuth, then you you should have an url looking like this: https://github.com/login/oauth/authorize?client_id=<client-id>&scope=public_repo&redirect_uri=<redirect-uri>