Trouble connecting to GrapheneDB

131 views
Skip to first unread message

Øystein Jakobsen

unread,
Sep 20, 2014, 6:21:21 PM9/20/14
to clojur...@googlegroups.com
I'm using neocons 3.0.0 and am now in a process of moving my Neo4j database to GrapheneDB. But I'm having trouble connecting. A call to
(nr/connect url user pwd)
returns a connection that seems ok. But when I try 
(cypher/tquery conn cypher params))
I get a 401:

ExceptionInfo clj-http: status 401 {:orig-content-encoding nil, :trace-redirects ["http://mydatabase.sb02.stations.graphenedb.com:24789/db/data/cypher"], :request-time 254, :status 401, :headers {"Connection" "close", "WWW-Authenticate" "Basic realm=\"Neo4j REST\"", "Content-Length" "68", "Content-Type" "text/plain", "Access-Control-Allow-Origin" "*", "Server" "GrapheneDB/Neo4j"}, :body "Authentication is possible but has failed or not yet been provided.\n"}  clj-http.client/wrap-exceptions/fn--2985 (client.clj:155)

The url, user and password are all correct, 'cos if I try with a wrong password the connect call fails. So the problem is when passing a connection to tquery.

Any ideas?

Regards,

Øystein Jakobsen
Oslo, Norway

Rohit Aggarwal

unread,
Sep 21, 2014, 4:10:12 AM9/21/14
to clojur...@googlegroups.com
Hi,
I haven't explicitly tested against GrapheneDB, but it's docs claims that Necons driver should work (http://docs.graphenedb.com/faq.html#supported-drivers).

I'll have a look at the over the next few days.

Cheers
Rohit

Øystein Jakobsen

unread,
Sep 21, 2014, 8:08:05 AM9/21/14
to clojur...@googlegroups.com
Thanks Rohit.

I intercepted traffic using WebScrarab, and what I see is the following:
  • The first GET to /db/data (the connect) has an Authorization header and returns 200 OK
  • The second POST to /db/data/cypher (the tquery) does not have an Authorization header and returns 401
If I add the correct Authorization header to the POST using WebScarab as proxy then GrapheneDB returns 200 OK with correct Cypher results.

Rohit Aggarwal

unread,
Sep 21, 2014, 9:28:26 AM9/21/14
to clojur...@googlegroups.com
That's really useful info. I now know where to look. 

Thanks

--
Documentation: http://clojureneo4j.info
Issues: https://github.com/michaelklishin/neocons/issues
 
More Clojure libraries: http://clojurewerkz.org
---
You received this message because you are subscribed to the Google Groups "clojure-neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-neo4...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojure-neo4j.
For more options, visit https://groups.google.com/d/optout.

Øystein Jakobsen

unread,
Sep 21, 2014, 9:31:33 AM9/21/14
to clojur...@googlegroups.com
Seems like connect returns a map like this:

{:http-auth [username password] ...}

but it should actually return something like this:

{:http-auth {:basic-auth [username password]} ...}

If I change the connection map returned by connect like that and pass it to tquery it works smoothly.

I'm running neocons 3.0.0 from clojars.org but maybe this version isn't the latest. I see a commit https://github.com/michaelklishin/neocons/commit/d3abf874d6b7db733bd7ad17dc1aa2f8dde76aac that might have something to do with this...

Michael Hunger

unread,
Sep 21, 2014, 9:54:21 AM9/21/14
to clojur...@googlegroups.com
Perhaps you can add a test, fix it and send a PR to the repo? That would be very appreciated.

Cheers, Michael

--

Øystein Jakobsen

unread,
Sep 21, 2014, 10:42:34 AM9/21/14
to clojur...@googlegroups.com
I'll check if the HEAD revision works better than the one on Clojars, and if not I will try to do that :)

Øystein Jakobsen

unread,
Sep 23, 2014, 2:59:05 AM9/23/14
to clojur...@googlegroups.com
Forked the project and set up to run the basic authentication tests using Apache as proxy against a local Neo4j instance. The all pass. But - I notice that the connection object returned from connect looks something like this:

{
     :
     :
}

The connection object "points" directly to the Neo4j instance, so when the connection is used then subsequent calls effectively bypasses the proxy (and the authentication). I suspect that is why some of the tests succeed even if no authentication header is sent.

When I change the tests to run against a GrapheneDB instance then 3 of the assertions fail.

Nice if someone can check my results, i.e. see what their connection objects look like - I might have configured the Apache proxy wrongly.

I will try to look into the problem and provide a fix for it.

Rohit Aggarwal

unread,
Sep 23, 2014, 3:53:32 AM9/23/14
to clojur...@googlegroups.com
Thanks Øystein! 

The connection object does indeed look like as you have described as neocons is simply using the URIs provided by neo4j server. I can see how it can cause issues. 

I've never used GrapheneDB but I'll sign up for it and test neocons against it. 

If need me to look over something, do let me know.

Cheers!

Rohit

Rohit Aggarwal

unread,
Sep 23, 2014, 5:25:50 AM9/23/14
to clojur...@googlegroups.com
Øystein,

This maybe of some help to you as well.


Essentially you can see what request neocons is actually making.

Rohit Aggarwal

unread,
Sep 23, 2014, 5:41:45 AM9/23/14
to clojur...@googlegroups.com
Øystein,
I've got a branch of neocons called graphene-db which seems to work with the following code:

https://gist.github.com/ducky427/d40ca4487a7b6f4726ff

Could you see if my branch would fix your issues?

cheers
Rohit

Øystein Jakobsen

unread,
Sep 23, 2014, 8:14:30 AM9/23/14
to clojur...@googlegroups.com
Seems promising! The unit tests all work now when modified to directly connect to GrapheneDB. Except for the first test which should expect 403 FORBIDDEN which is (correctly) returned by GrapheneDB when passed a wrong password.

The first test should also be modified to fail if the authentication actually succeeds despite given a wrong password:

    (deftest ^{:http-auth true} test-connection-and-discovery-using-user-info-in-string-uri
      (try
        (neorest/connect "http://neocons:incorrec7-pazzwd @ neo4j-proxy.local/db/data/")
        (is false)
        (catch Exception e
          (let [d (.getData e)]
            (is (= (-> d :object :status) 403))))))

The try-catch in the second test is not needed I think.

Will try my own software with the modified neocons code a bit later to day. Thanks for all your help!

Regards,
Øystein

Michael Klishin

unread,
Sep 25, 2014, 2:11:48 AM9/25/14
to clojur...@googlegroups.com, Øystein Jakobsen
 On 23 September 2014 at 16:14:30, Øystein Jakobsen (oeys...@gmail.com) wrote:
> The try-catch in the second test is not needed I think.

Feel free to submit a pull request that updates the test.
--
@michaelklishin, github.com/michaelklishin

Øystein Jakobsen

unread,
Sep 28, 2014, 4:22:09 PM9/28/14
to clojur...@googlegroups.com, oeys...@gmail.com
Done :)

Michael Klishin

unread,
Sep 28, 2014, 4:58:33 PM9/28/14
to clojur...@googlegroups.com, Øystein Jakobsen
 On 29 September 2014 at 00:22:09, Øystein Jakobsen (oeys...@gmail.com) wrote:
> Done :)

Thank you.

Merged, in 3.1.0-beta1:

https://clojars.org/clojurewerkz/neocons/versions/3.1.0-beta1
--
@michaelklishin, github.com/michaelklishin
Reply all
Reply to author
Forward
0 new messages