[SERVER-5082] Queries with slaveOk() do not reauthenticate when credentials change and an admin user exists. Created: 24/Feb/12 Updated: 15/Aug/12 Resolved: 22/May/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Client, Replication, Security |
| Affects Version/s: | 2.0.2, 2.0.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Rob LaRubbio | Assignee: | Ben Becker |
| Resolution: | Duplicate | Votes: | 4 |
| Labels: | authentication | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Ubuntu, C++ driver |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
I don't have a reproducible test case, but this issue was seen in production with two different user/database combination two distinct times. We can not run with slave_ok in production because of it. Each time the issue persisted until slave_ok was removed as an option to query. We are using the luamongo (https://github.com/moai/luamongo) driver which is a thin wrapper around the c++ driver. We never saw the issue when on mongodb 1.8, we first ran into the issue after updating to 2.0.2. Originally we thought it was because we were still using a lua driver compiled against the 1.8.X C++ driver but the issue continued after upgrading to the 2.0.2 version of the driver. When a query is sent to a secondary this is the return: [ {"code":10057,"$err":"unauthorized db:<db name> lock type:-1 client:50.18.245.77"}] Any lua query, even basic one's like the following will generate the error: local cursor = mongodb:query('mydb.datastore', ' {key:"value"}', nil, nil, nil, 4) |
| Comments |
| Comment by Tad Marshall [ 25/Jun/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Setting Backport to No because this ticket was marked as a duplicate of | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Ben Becker [ 22/May/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This appears to have been fixed because of | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Ben Becker [ 03/Apr/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
It looks like we can replace the call to replSetGetStats with isMaster to avoid requiring admin credentials for each secondary connection. checkSlave() may also need to reauth even if it was the last slave selected. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Ben Becker [ 02/Apr/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue appears to be in the replica set secondary connection logic. We never attempt to reauthenticate when using a secondary. Existing behavior: on the second query, the auth message is sent over connection #6, and the query itself is sent over connection #7. Note that neither of these are actually sent to the secondary server; only the primary.
Tested a quick work-around to confirm the cause of the bug, and now query.lua successfully authenticates:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 29/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Got it. Thanks for the update and thanks for your work on this, I appreciate it. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by siddharth.singh@10gen.com [ 29/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Sorry, I should have been more explicit. So I tried to reproduce it multiple times over several days and saw it happen only once. I am afraid, I don't have a good answer as to why I can't reproduce it consistently. It would be great if I saw it happen reliably cause then I could fix it. When the database collection is empty I see this:
After I add a document to the values collection to both database a and b, I see this:
In case you were curious I have also attached the server logs primary.log and secondary.log while I run the client. I am going to continue trying to reproduce this and will update the ticket as soon as I find something. I edited the Lua tag from the bug issue. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 29/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Also one other request can we remove "Lua (luamongo)" from the environment since I can reproduce it directly from c++ code without using any Lua. Thanks. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 29/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I'm not sure I'm completely understand your comment. When you say "reliable reproduce" does that mean you've seen the issue sporadically but not consistently? What happened when you ran the latest version of the attached c++ code? I can try that again with a version of 2.0.4, but in the latest repro cases for me I'm pretty much using a completely clean server with downloads directly from 10gen (and no lua), so I'd really like to understand why it happens reliable for me but you guys can't reproduce it. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by siddharth.singh@10gen.com [ 29/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Rob, I haven't been able to reliably reproduce this. I tried taking a diff between 1.8.5 and 2.0.2 code to see if we made any changes. The diff, however is big and its difficult to reverse engineer the issue. I also asked another engineer to try to reproduce this but he didn't see it happen either. You can try our recently released 2.0.4 or checkout mongo (r2.1.0 tag) from our master branch on github and see if that helps. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 28/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I wanted to see if you are able to reproduce this issue with the latest attached c++ code. Thanks. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 19/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
It's possible I may have forgotten to delete that line before adding it to the ticket. The servers were up and running in a replica set since I would connect to the shell and run rs.status() before running the test to make sure all servers had joined. I don't have the output anymore but I had two servers in the set, one was primary and the other secondary. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by siddharth.singh@10gen.com [ 19/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi, In the repro steps you sent me, there was this step :
mongo admin --port 27018 After which you kill the servers and restart them as replica sets. Can you confirm that you executed the above step. You should not have been able to start the replica set and should have received an error saying ""errmsg" : "couldn't initiate : member 127.0.0.1:27018 has data already, cannot initiate set. All members except initiator must be empty." I figure that you might have mistakenly wrote that, but just to make sure. Meanwhile i will dig into the api calls. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 19/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The client code you added to this ticket reproduces the error for me. When I first ran the code it throws an exception before getting to the line that has the issue:
I modified the code so if first checked more() on the cursor and when I reran it I reproduced the error:
The only change to the code you added to the ticket was checking more before calling next():
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 17/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Thanks, but stop working on the weekend. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by siddharth.singh@10gen.com [ 17/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Rob, With the steps that you reported above I was able to reproduce the behavior. To make sure that the issue is with the C++ driver or with the server, I went ahead and wrote a C++ client (slaveQueryOkTest.cpp) and tested it against the database. The client code works fine which makes me believe that the issue is with the lua wrapper. Can you please run this client in your environment. Configure your replica set pretty much the same way you did above and please run this and let me know if it fails. This link might be of help : http://www.mongodb.org/pages/viewpage.action?pageId=133415#C%2B%2BTutorial-WritingClientCode Thanks. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 13/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I was able to reproduce this using several different setups. The issue occured in all configurations. All servers are running ubuntu First attempt used 64bit 11.04 client and 32bit (by mistake) 11.10 server running 2.0.3 installed via apt-get. The driver is the one we use in production (compiled from a tarball downloaded 1/24/12). This reproduced the problem. Second attempt pulled master from git of luamongo and the latest version of the c++ driver. Same servers and it reproduced the problem. Third attempt moved to a new 64bit 11.10 server. I pulled master of luamongo, the latest tarball of the driver and the 2.0.2 tarball of mongo on the server. I built all locally. Still exhibits the issue. Here are the detailed steps I took: Create EC2 machine with ami from ubuntu (ami-6da8f128 http://cloud-images.ubuntu.com/releases/11.10/release/)
I'm attaching the query.lua I used. You should be able to run it without changing it. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by siddharth.singh@10gen.com [ 12/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I am running ubuntu 11.10 on a 64 bit machine. Mongo version is v2.0.2, Gcc version is 4.6.1, Lua version is 5.1.5 along with compat-5.1r5. I compiled the latest C++ driver (http://dl.mongodb.org/dl/cxx-driver) to compile against lua. I compiled mongo from source but it won't make any difference if you just picked up the binaries (as per your machine) from (http://www.mongodb.org/downloads) and executed it. I then follow appropriate sections from (http://www.mongodb.org/display/DOCS/Security+and+Authentication#SecurityandAuthentication-ReplicaSetandShardingAuthentication) to setup a replica set authentication. I then added users for specific databases, started the replica set and executed the lua script. Let me know how this goes. On a separate note, the digestPassword in lua definitely needs some cleanup to make sure it is not doing the opposite of what it claims to do. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 12/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Can you let me know more about your setup? Our production system is running ubuntu 11.04. The mongodb we are running is 2.0.2 installed from the 10gen package repository (package mongodb-10gen) I'm not aware what could be custom on the server so when setting up a test system I'd probably have the same setup as our production system. So if you pointers on what would be considered a clean system I can set that up. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 12/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Correct, I was only looking at test case 1. I don't think json has any affect on the issue, I'm just using it as a tool to inspect and print out lua tables. In our case when we issue the query we get back a lua table that contains the error message. You can also view it with this code:
If you are able to iterate over the results and those results contain the expect data not the error table then there is something else different between our setups. I'm not sure what it could be so if you have ideas I can collect that information for you. Also in our setup we auth with digested passwords so we set digestPassword=false in the auth call. However I just reproduced the issue using plain text non-digested passwords. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by siddharth.singh@10gen.com [ 12/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Rob, I included and printed the json and it shows everything as expected. I am even able to iterate over the cursor and print the results. As much as I want to see it break (so that I can fix it), it doesn't. Everything works as expected. I understand that this is reproducible in your production but can you please try to isolate this behavior on a test mongodb installation, separately. Production environments typically have a complex customized setup and isolating any such behavior becomes hard, especially for someone like when I don't know the behind the scenes setup. It would be great if you can reproduce this behavior on a clean mongodb test install. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by siddharth.singh@10gen.com [ 12/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Point (1) is not correct. If you see Test Case 2 and Test Case 3 in the code, I do authenticate the users against different database. As for point 2, I was actually going a step ahead and was printing the values from the cursor, just to be very sure. If there would have been an issue the iterating over the cursor would not have returned any results. I removed that piece of code to minimize the output for you. I will go ahead, include json and report back. I doubt if that's going to make any difference but I want to make sure to cover all the bases. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 12/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Your script reproduces the error, but I notice two things that you need to adjust: 1) All of your users are authenticating against the same db. For us all of our users are in different dbs. 2) The query returns a cursor, so calling assert will not show the error. You need to inspect the return value. That's why I include json. This will not show the error: local q = assert(mongo:query('values',' {a:10}' , nil, nil, nil, 4, nil)) Since mongo:query doesn't raise an error. This will show you the error: local q = assert(mongo:query('values',' {a:10}' , nil, nil, nil, 4, nil)) That print will return this: {"code":10057,"$err":"unauthorized db:db2 lock type:-1 client:50.18.15.22"}Instead of the object I expected it to load. So if I modify your script so it connects to our production servers and make the two changes mentioned above this reproduces the issue. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by siddharth.singh@10gen.com [ 12/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yes I did. And I ran it (with appropriate username/passwd) and it worked fine. I extended the script to test even more cases, all of which worked fine. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by siddharth.singh@10gen.com [ 12/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I agree, that digestPassword should stop authentication completely. I still wanted to point that one out to make sure that you are aware about it. Getting back to your issue, please see the attached script (authQueryTest.lua). Test Case 2 and 3 is how I believe you are using it. All the tests succeed for me and I am not able to repro the case. Could you play with this script (perhaps on some test/prototype machine with mongo on it) and see if you can break it. If it does break, please feel free to report it on this thread. I did a quick search on JIRA trying to find if anybody else had reported a similar issue but nothing came up. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 12/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Also I just want to see if you've looked at the query.lua script I attached that I used to reproduce the issue. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 12/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
One additional point, after we upgraded the database we also did not change the version of the c++ driver the lua driver was linked against. So truly the only thing to change was on the server side. I originally thought this issue was because of the mis-match in c++ driver versions but it persisted after I upgraded the client to match the server. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 12/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
If it was digestPassword then we wouldn't have been able to auth at all. I'm pretty sure this is something on the server side. (I'm almost positive). We were using 1.8.5 of the server with slaveOk and the system was running fine. We then upgraded our server to 2.0.2 without changing any lua code or the lua driver and we started to see this issue. The only piece of our stack that changed was the server. In my testing it looks like if I try to re-auth an existing connection that had already been authed then the auth succeeds, but if a query is sent to the secondary it fails with an authorized exception. That is reproducible for me. So what it looks like is happening is I have two users and one connection. User A has Database 1 The do not have access to each others database. I have a replica set configured. When my app starts up I create a single connection called conn. I do not immediately auth the connection. In a loop, when I receive an http request I: The loop succeeds on the auth regardless of the user, but the query will only work for the first user to make a request. So it seems like the second call to auth allows the new user to query the primary but not the secondary. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by siddharth.singh@10gen.com [ 12/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Rob, There is something that caught my eye and I wanted to point that out to you and see if that could be the potential root cause. If you look at lua documentation (https://github.com/moai/luamongo/wiki/MongoConnection) it says that if password is plain text digestPassword should In the code (https://github.com/moai/luamongo/blob/master/mongo_dbclient.cpp) line 117 the comment says the opposite thing. It says set digestPassword to true if password is pre-digested. Those seem like two contradicting statements. I tried making some sense out of code, line 131 (https://github.com/moai/luamongo/blob/master/mongo_dbclient.cpp) but I am not familiar with lua semantics so I could not go far. Passwords on my machine are not set in plain text. Here's what I am seeing on my machine: i) When I set my digestPassword as false I am not able to auth at all. Not even once. ii) On setting it to true everything works fine for me. Multiple users, mulitple databases, multiple collections etc. everything ran as expected I ran quite a few tests trying different combinations and all of them passed successfully. iii) Can you sanity check the digestPassword field with respect to your environment and see if that is causing the potential issue. Thanks. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 08/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I'm close to a repro case, it looks like the issue happens if you reauth a connection. I can repro it on our production servers, I don't have an isolated version of the script but I'll attach what I have with our usernames/passwords removed. Basically if you create two users on your test cluster and modify your query script so it essentially looks like this: create connection auth user1 auth user2 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by siddharth.singh@10gen.com [ 07/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Rob, Please see the updated script (query.lua). I am not able to reproduce the behavior and the querying successfully works for me, with and without slaveOk. Are you seeing this happen on a more deterministic basis ? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 07/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Sorry I didn't realize you were thinking the error came from authing the connection. For more information to hopefully resolve the confusion, we initial setup our connections like this:
The connect succeeds and we have no issue at this point. Now that our app has started up we start to listen for http connections and service each one. When a connection comes in we set up our sandbox and connect to a users database like this:
That code succeeds. Eventually we load the users code and execute it. That code runs in our lua sandbox and eventually executes code like this:
In our sandbox we wrap 'mongodb' and expose it to users as 'mongo'. The modification is very slight. This is almost an exact copy of the sandboxing we do on top of luamongo (I've removed all methods except query):
So the issue isn't that the auth fails, it appears that valid auth isn't forwarded to a secondary when the drive sends a query their via slaveOk. Sorry for the confusion. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 07/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Thanks for looking into this, but it looks like you've been digging into the wrong call. We aren't getting the error when we make the auth call, we get the error when we attempt to issue a query. Authing the connection works fine (and we don't direct the auth to a particular server, but rather at the replicaset in general) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by siddharth.singh@10gen.com [ 07/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Rob, I tried reproducing this issue on my machine but with no success. I wrote a C++ client and a lua script (please see attached files) hoping to see the reported behavior and fix it. Unfortunately, I could not reproduce the reported behavior and authentication worked fine when run against, both, the primary and the secondary. I understand that this doesn't help you with your production issue of not being able to run with slaveOk on secondaries. My best guess at this point of time is that it might have to do something with client key, that you reported earlier. Thank for you for filing this ticket though. In future if we see a similar issue, it will be a good data point to refer to. Also, if you are able to get a reproducible test case for it, please feel free to file an updated ticket with us. Thanks. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Rob LaRubbio [ 06/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
We're using Lua 5.1.4 As far as the lua script, we building a paas that game developers can use to run lua code that servers as the backend for their games. We sandox our lua calls, the one for query looks like this:
prefix is set to the users database. A simple user script that was failing looked like this:
The actual script had a little more to it like getting a param from the query string and doing something from the result, but the additionally code was very limited and above is an acurate representation of the mongodb interactions. Going into as much detail as I can, within our backend system we create three connections to two seperate mongodb replica sets. One replica set (we'll call it "master") holds our master database that we use for user accounts. The second (We'll call it "users") holds users data and code within gridfs. We recent split our master database out into it's own server, but we had the same issue when it was a seperate db within a single replica set. The two connections we create to the users server have to do with a user accessing the server with a clientkey. In that case there are two logical users of the service, one is the user accessing it and the other is the user who wrote the service. In that example we'll auth each connection against each users database. So the basic auth flow is as follows: 1) At startup time we create three connections. We auth the connection to our master database but not the two connections to our users database. The connection that was failing was to the users database in situations without a client key. I did not see the error in cases where the system was called with a client key but again since I'm not able to reliable reproduce this that might be important or just coincidental. We do cache the authentication so in the event a user calls the system twice in a row we don't re-auth. I a small percentage of uses use the clientkey feature so that connection was probably not being re-authed as frequently as the other. We added that cacheing since the log message for each auth was filling up our disk (I put a pull request in for that) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by siddharth.singh@10gen.com [ 06/Mar/12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Rob, I am trying to reproduce this issue. It will be helpful if you could please send me the following: i) version of lua you are using. ii) lua script showing exactly how are you using the luamongo binding. I understand that this is not definitely reproducible but it will give me a good starting point. iii) If you could also describe your authentication setup in general, that would be great. Thanks. |