Authorization fails - verbose option?

[dazza-codes]

How are the authorization headers set and debugged? Is there a verbose option, like the curl -v option? Here's the code that fails (substitute real auth parameters), which is a query on a MarkLogic SPARQL endpoint where the Kb is running on port 8322.

  auth_code = Base64.encode64('myUser:myPass').chomp
  auth_header= {'Authorization' => "Basic #{auth_code}"}
  uri = 'http://devbox.example.org:8322/v1/graphs/sparql?'
  sparql = SPARQL::Client.new(uri, {headers: auth_header} )
  q = sparql.select.where([:s, :p, :o]).limit(10)
  q.each_statement {|s| puts s.inspect }
  SPARQL::Client::ClientError: <rapi:error xmlns:rapi="http://marklogic.com/rest-api"><rapi:status-code>401</rapi:status-code><rapi:status>Failed Auth</rapi:status><rapi:message-code/><rapi:message>Unauthenticated</rapi:message></rapi:error>
  Processing query SELECT * WHERE { ?s ?p ?o . } LIMIT 10
  from /home/dlweber/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/sparql-client-1.1.3.1/lib/sparql/client.rb:342:in `block in response'

The same host and auth parameters work with curl, e.g.

curl -v --anyauth --user myUser:myPass "http:///devbox.example.org:8322/v1/graphs/sparql?query=DESCRIBE <http://id.loc.gov/authorities/names/n2006182879>"
* Hostname was NOT found in DNS cache
*   Trying 172.XX.XX.XX...
* Connected to xxx (172.xx.xx.xx) port 8322 (#0)
> GET /v1/graphs/sparql?query=DESCRIBE <http://id.loc.gov/authorities/names/n2006182879> HTTP/1.1
> User-Agent: curl/7.37.1
> Host: xxx:8322
> Accept: */*
> 
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Digest realm="public", qop="auth", nonce="d01666e5d0158e66faa415f4fb21ccc6", opaque="5a267bbd6a277eb9"
< Content-type: application/xml
* Server MarkLogic is not blacklisted
< Server: MarkLogic
< Content-Length: 211
< Connection: close
< 
* Closing connection 0
* Issue another request to this URL: 'http://xxx:8322/v1/graphs/sparql?query=DESCRIBE+<http://id.loc.gov/authorities/names/n2006182879>'
* Hostname was found in DNS cache
*   Trying 172.xx.xx.xx...
* Connected to xxx (172.xx.xx.xx) port 8322 (#1)
* Server auth using Digest with user 'myUser'
> GET /v1/graphs/sparql?query=DESCRIBE+<http://id.loc.gov/authorities/names/n2006182879> HTTP/1.1
> Authorization: Digest username="myUser", realm="public", nonce="d01666e5d0158e66faa415f4fb21ccc6", uri="/v1/graphs/sparql?query=DESCRIBE+<http://id.loc.gov/authorities/names/n2006182879>", cnonce="NWFmZmNlYmM0ZWZhMWY1NmVmMzZkYjc2NTUyMGU0NTU=", nc=00000001, qop=auth, response="e2eed963198b23a165e652abc7bcf3c3", opaque="5a267bbd6a277eb9"
> User-Agent: curl/7.37.1
> Host: xxx:8322
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-type: application/n-quads
* Server MarkLogic is not blacklisted
< Server: MarkLogic
< Content-Length: 1155
< Connection: Keep-Alive
< Keep-Alive: timeout=5

[gkellogg]

I'm afraid I an't try this, as devbox.example.org isn't an endpoint i can poke.

Setting the Authorization header as you do seems correct.

The only thing I can suggest is to either use a debugger (byebug for example) in the #response method at the line referenced to look more completely at the response messages, or clone the repo and instrument the code to dump this information out.

Authorization issues can be difficult, and I've used it most successfully when including authorization information (or a grant token) as part of the endpoint URL.