We need to test a site that require windows authentication. We have tried to automate it using Casperjs, but we kept on getting a 401.
We found that others had similar issue based on the following discussion . However, the discussion was closed with no real solutions.
Someone in that discussion noted that he/she used page.customHeader with additional workarounds, but no real steps were provided on how to get this to work.
We also tried updating url to http://username:passowrd#domain.com pattern & even that did not helped.
See Fiddler's sample response when i tried this in the
GET / HTTP/1.1
Host: host
HTTP/1.1 401 Access Denied
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
GET / HTTP/1.1
Host: host
Authorization: NTLM TlRMTVNTUAABAAAAB4IAoAAAAAAAAAAAAAAAAAAAAAB=
HTTP/1.1 401 Access Denied
WWW-Authenticate: NTLM TlRMTVNTUAACAAAADAAMADAAAAAFgoGgCY6qiih5j bAAAAAAAAAAAH4AfgA8AAAAUABPAFIAVAA4ADAAAgAMAFAATwBSAFQA OAAwAAEACgBKAEwASQBNAEEABAAkAH
Actually there was a good workaround sugguested in issue discussion on PhantomJS github. You could use a local NTLM proxy and connect to it via CasperJS like so:
casperjs --proxy=localhost:3133 --ignore-ssl-error=true --ssl-protocol=any script.js
Related
I am trying to test an API hosted using AWS API Gateway and always getting following error:
Error: socket hang up
Request Headers
clientId: system
Authorization: //Correct Auth Token
User-Agent: PostmanRuntime/7.26.8
Accept: */*
Host: //API Host URL
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
However, when I pass in an invalid Auth Token (like TEST), I actually receive a 403 error as expected. I can also see logs in CloudWatch confirming the call reached the authorizer.
CloudWatch Logs
The same API works for other people perfectly fine.
I have tried almost every resolution I found online related to this issue like I turned off 'SSL Certificate Verification' in Postman and kept proxy settings same as my colleagues. Tried to hit the API after disconnecting VPN as well but nothing worked for me.
Could anyone please help me with this.
Thanks in advance.
I tried to publish a message to both the default exchange and also some other exchange via the HTTP Management API but I always get back an authorization error.
curl -i -u myuser:mypw -XPOST -d'{"properties":{},"routing_key":"my_key","payload":"my body","payload_encoding":"string"}' https://myinstance.rmq.cloudamqp.com/api/exchanges/vhost/myvhost/publish
HTTP/1.1 401 Unauthorized
Server: nginx/1.14.2
Date: Mon, 01 Apr 2019 05:27:10 GMT
Content-Type: application/json
Content-Length: 53
Connection: keep-alive
content-security-policy: default-src 'self'
vary: accept, accept-encoding, origin
{"error":"not_authorised","reason":"Access refused."}%
I tried it both on a self hosted RabbitMQ (installed via helm on k8s) and our CloudAMQP instance.
But if I login on the Management Web UI with the very same user then I can publish a message to the exchange and also consume from a queue.
I expect that the Management Web UI just uses the HTTP API for performing this actions so I am confused why it works when I do it via the UI.
Reading all vhost on the other hand works also with the HTTP API.
curl -i -u myuser:mypw https://myinstance.rmq.cloudamqp.com/api/vhosts
HTTP/1.1 200 OK
Can somebody explain to me whats going on there? What puzzels me the most is the fact that it works on the UI using the same user:pw.
I figured out the problem, I did use the wrong URL path.
For vhost: / and the default exchange it should be:
http://myinstance.rmq.cloudamqp.com/api/exchanges/%2F/amq.default/publish
In my case, using the CloudAmqp free plan, I needed to use my user name as vHost in rhe URL:
https://myinstance.rmq.cloudamqp.com/api/exchanges/[myrandomusernamefromfreeplan]/amq.default/publish
When I send a http request to my couchdb server like it is shown in the docs here CouchDB Proxy Authentication, it doesn't give the response shown in the docs, just empty data. What am I doing wrong?
Also, am I able to start a session with this Proxy Auth? If I try a POST /_session, I get 500 error code.
GET /_session HTTP/1.1
Host: 127.0.0.2:5984
User-Agent: curl/7.51.0
Accept: application/json
Content-Type: application/json; charset=utf-8
X-Auth-CouchDB-UserName: john
X-Auth-CouchDB-Roles: blogger
< HTTP/1.1 200 OK
< Cache-Control: must-revalidate
< Content-Length: 132
< Content-Type: application/json
< Date: Sun, 06 Nov 2016 01:10:58 GMT
< Server: CouchDB/2.0.0 (Erlang OTP/17)
<
{"ok":true,"userCtx":{"name":null,"roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["cookie","default"]}}
I found in the CouchDB issue tracker that the Proxy Authentication is broken in version 2.0.0. Either that or the docs aren't updated to indicate that it only works with clusters or something. I changed back to version 1.6.1 and everything works fine. I must say that the documentation for how Proxy Authentication works is very poor.
How it works is you need your third party authentication server to have the "[couch_httpd_auth] secret" and when a client authenticates, you need to generate a HMAC-SHA1 token by combining the username and secret. Then, on any http requests you make from the client to the CouchDB server, if you include all the headers:
X-Auth-CouchDB-Roles
X-Auth-CouchDB-UserName
X-Auth-CouchDB-Token
that request will be authenticated as a user client.
Also, it is not mentioned in the docs, but POST on the /_session API using these headers does nothing.
It's not the Proxy Authentication itself which is broken in CouchDB 2.0, it's just that in the current release there's no way to configure the authentication handlers like there was in the old 1.6 days.
There are some patches mentioned in the issue tracker which add proxy authentication to the list of authentication handlers. Furthermore there was a pull request which was accepted and merged which brings back configurability to CouchDB 2.0.
However in order to take advantage of those I'm afraid you either have to wait until the next release, or build CouchDB 2.0 yourself from the sources.
Proxy authentication is fixed as of CouchDB 2.1.1. The latest (>2.1.1) documentation shows how to configure proxy authentication again, along with the important proxy_use_secret option.
I have a localhost setup using MAMP PRO and XIP.IO for sharing on my local network.
I'm also trying to test API requests from with the same application but I keep getting the following error in the log file even though I am using the correct API credentials which work on a remote server.
2015-12-20T12:52:52+00:00 DEBUG (7): HTTP/1.1 401 Unauthorized
Content-type: text/html
Date: Sun, 20 Dec 2015 12:52:52 GMT
Server: nginx
Www-authenticate: Basic realm="very closed site"
Content-length: 188
Connection: keep-alive
<html>
<head><title>401 Authorization Required</title></head>
<body bgcolor="white">
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx</center>
</body>
</html>
If this is indeed due to being on a localhost is there a way to recieve API callbacks using MAMP PRO?
If you want the third party API to be able to send you a post back, your local website/app must be accessible when entering your public IP.
So if I understand your problem you just have to configure your router (or internet provider box) and open a port that you redirect to your local MAMP Pro. You can find a lot of tutorial for "Access MAMP Pro remotely"
WARNING : Do this for tests and then close the port you openned not to leave a security breach
I'm having a problem with triggering builds in Jenkins with authentication enabled and wondering if anyone has ideas.
I have Global Security configured to use LDAP with "Project-based Matrix Authorization Strategy" enabled. The "Anonymous" user has the "Job > Build" privilege, and no other privileges (in particular, the "Anonymous" user does NOT have "Overall > Read" privilege, since I don't want everyone to be able to view the list of jobs and other general information).
I want an automated script to be able to trigger a build using the "Trigger Builds Remotely" feature, where I specify a ?token=[token] value in the URL and the standard authentication should be bypassed, as long as the [token] value matches the one I set in the job's Configure page. The goal is to NOT need to provide a regular username/password in the request but simply provide the token for this specific job.
The documentation seems to indicate this should work:
https://wiki.jenkins-ci.org/display/JENKINS/Quick+and+Simple+Security
So specifically, I am expecting this HTTP request to work:
curl -i https://jenkinsHost/job/ProjectName/build?token=test
But I get:
[~]$ curl -i https://jenkinsHost/job/ProjectName/build?token=test
HTTP/1.1 403 Forbidden
Date: Sat, 27 Apr 2013 23:17:03 GMT
Server: Winstone Servlet Engine v0.9.10
Content-Type: text/html;charset=UTF-8
Content-Length: 629
X-Powered-By: Servlet/2.5 (Winstone/0.9.10)
Set-Cookie: JSESSIONID.e9bc4765=e1f0a30b9f04b3740bae527a7822b2d5; Path=/; HttpOnly
Connection: close
<html><head><meta http-equiv='refresh' content='1;url=/login?from=%2Fjob%2FProjectName%2Fbuild%3Ftoken%3Dtest'/>
<script>
window.location.replace('/login?from=%2Fjob%2FProjectName%2Fbuild%3Ftoken%3Dtest');</script>
</head>
<body style='background-color:white; color:white;'>
Authentication required
</body></html>
When I DO use API authentication, the request works:
curl --username "test_user:API_KEY" https://hostname/job/ProjectName/build?token=test
But again, according to the documentation I think it is supposed to bypass the global authentication if ?token is present and matches the project token I configure. Why is this not working? What other information/logs can I provide?
There's a new plugin that allows you to do that even when Jenkins prohibits anonymous read access:
Build Token Root Plugin
Use:
$ curl 'http://jenkins/buildByToken/build?job=jobname&token=mytoken'
Scheduled.
Likewise with buildWithParameters.
Example for using the "Build Authorization Token Root" plugin with POST:
wget --post-data="job=MyJob&token=SECRET&MyParameter=hello" http://servername/jenkins/buildByToken/buildWithParameters
note that "Trigger Builds Remotely" must be activated for this job (with authorization token "SECRET")