401 after logging in

[Matthew]

I'm running through the cookbook examples https://fluidinfo.com/cookbook/.
The examples work fine until I log on with my username and password.
After that, no matter what query I make (GET or PUT), I get a 401
error:

{'status': '401', 'content-length': '12', 'server': 'nginx/0.7.65',
'connection': 'keep-alive', 'date': 'Wed, 06 Jul 2011 00:14:22 GMT',
'content-type': 'text/html', 'www-authenticate': 'basic
realm="fluidinfo.com"'}

'Unauthorized'

Why would I anonymously be allowed to query, but not while logged in?

Thanks,
Matthew

[Nicholas Tollervey]

Hi Matthew,

First of all, sorry that you're having problems. I wrote the cookbook and checked each of the examples so something must have gone wrong.

Let's start with a *very* basic check. I know this is obvious and you've probably checked already but can I just make sure that you're using the correct credentials when you log in..? 

The reason I ask is that if you *don't* use the correct credentials then *every* request you make to Fluidinfo will result in a "401 - Unauthorized" result (which sounds like the behaviour you're experiencing). If you're using what you think are the right credentials but can't be certain then visit https://fluidinfo.com/accounts/password_reset/ to reset your password just to make sure.

Sorry this sounds obvious, but I'd like to make sure we exclude the simplest gotcha.

Assuming you do have the right credentials it'd be very helpful for us if you could supply us with an example of a failing call to Fluidinfo. A simple cut and paste of what you're typing into the shell along with the result would be great.

Finally, you asked why an anonymous user might be able to query but an authenticated user could not. Well, as I mentioned before if you supply bad credentials *all* requests will result in a 401. However, there's another esoteric and rather silly way this situation might arise. If you're trying to use an endpoint with an associated permission policy:

{'policy': 'open', 'exceptions': ['user-foo', ]} 

Then the permission is open for *all* [including anonymous] except for "user-foo". Ergo, if you use user-foo's credentials then you'll be returned a 401. Clear..? :-)

Hope this answers your question and I'm more than happy to help in any way I can, just drop me a line directly or via this mailing list.

All the best,

Nicholas.

[Matthew]

Thanks, Nicholas. I actually did reset my password before posting,
just to be on the safe side, and got the same results. I'm on the
"create a namespace" portion of the cookbook.

Here is what I receive as the anonymous user:

>>> headers, response = fluidinfo.call('POST', '/namespaces/test', {'name':'childNamespace', 'description':'This is an example.'})
>>> headers
{'status': '401', 'x-fluiddb-path': 'create', 'transfer-encoding':
'chunked', 'content-type': 'text/html', 'x-fluiddb-request-id':
'vnpfrhtkroudaebi', 'server': 'nginx/0.7.65', 'x-fluiddb-action':
'namespaces', 'connection': 'keep-alive', 'date': 'Wed, 06 Jul 2011
15:51:40 GMT', 'x-fluiddb-error-class': 'TPathPermissionDenied', 'x-
fluiddb-category': 'test'}
>>> response
''

And here is what I receive logged in:

>>> fluidinfo.login('matthew', XXXXX)
>>> headers, response = fluidinfo.call('POST', '/namespaces/test', {'name':'childNamespace', 'description':'This is an example.'})
>>> headers
{'status': '401', 'x-fluiddb-path': 'create', 'transfer-encoding':
'chunked', 'content-type': 'text/html', 'x-fluiddb-request-id':
'fvgkleyateyzbjxt', 'server': 'nginx/0.7.65', 'x-fluiddb-action':
'namespaces', 'connection': 'keep-alive', 'date': 'Wed, 06 Jul 2011
15:54:23 GMT', 'x-fluiddb-error-class': 'TPathPermissionDenied', 'x-
fluiddb-category': 'test'}
>>> response
''

I also tried for my own name as the namespace. This worked in Prod,
but no in the Sandbox.

Prod:

>>> headers, response = fluidinfo.call('POST', '/namespaces/matthew', {'name':'childNamespace', 'description':'This is an example.'})
>>> headers
{'status': '201', 'content-length': '120', 'server': 'nginx/0.7.65',
'connection': 'keep-alive', 'location': 'https://fluiddb.fluidinfo.com/
namespaces/matthew/childNamespace', 'cache-control': 'no-cache',
'date': 'Wed, 06 Jul 2011 15:56:41 GMT', 'content-type': 'application/
json'}
>>> response
{u'id': u'2ec5e4bf-2c30-4232-89d2-10726bf40cae', u'URI': u'https://
fluiddb.fluidinfo.com/namespaces/matthew/childNamespace'}

Sandbox:

>>> headers, response = fluidinfo.call('POST', '/namespaces/matthew', {'name':'childNamespace', 'description':'This is an example.'})
>>> headers

{'status': '401', 'content-length': '12', 'server': 'nginx/0.7.65',

'connection': 'keep-alive', 'date': 'Wed, 06 Jul 2011 15:57:41 GMT',

'content-type': 'text/html', 'www-authenticate': 'basic
realm="fluidinfo.com"'}

>>> response
'Unauthorized'
>>>

I would love to be able to play in the Sandbox first (of course :)
while I learn before adding too many objects, etc. to my Prod
environment.

Let me know if you need any more details.

Thanks,
Matthew

On Jul 6, 5:09 am, Nicholas Tollervey <nt...@fluidinfo.com> wrote:
> Hi Matthew,
>
> First of all, sorry that you're having problems. I wrote the cookbook and
> checked each of the examples so something must have gone wrong.
>
> Let's start with a *very* basic check. I know this is obvious and you've
> probably checked already but can I just make sure that you're using the
> correct credentials when you log in..?
>
> The reason I ask is that if you *don't* use the correct credentials then
> *every* request you make to Fluidinfo will result in a "401 - Unauthorized"
> result (which sounds like the behaviour you're experiencing). If you're
> using what you think are the right credentials but can't be certain then

> visithttps://fluidinfo.com/accounts/password_reset/to reset your password

> just to make sure.
>
> Sorry this sounds obvious, but I'd like to make sure we exclude the simplest
> gotcha.
>
> Assuming you do have the right credentials it'd be very helpful for us if
> you could supply us with an example of a failing call to Fluidinfo. A simple
> cut and paste of what you're typing into the shell along with the result
> would be great.
>
> Finally, you asked why an anonymous user might be able to query but an
> authenticated user could not. Well, as I mentioned before if you supply bad
> credentials *all* requests will result in a 401. However, there's another
> esoteric and rather silly way this situation might arise. If you're trying
> to use an endpoint with an associated permission policy:
>
> {'policy': 'open', 'exceptions': ['user-foo', ]}
>
> Then the permission is open for *all* [including anonymous] except for
> "user-foo". Ergo, if you use user-foo's credentials then you'll be returned
> a 401. Clear..? :-)
>
> Hope this answers your question and I'm more than happy to help in any way I
> can, just drop me a line directly or via this mailing list.
>
> All the best,
>
> Nicholas.
>

> On 6 July 2011 01:18, Matthew <matthew.g.nor...@gmail.com> wrote:
>
>
>
>
>
>
>
> > I'm running through the cookbook exampleshttps://fluidinfo.com/cookbook/.

[Nicholas Tollervey]

Hi Matthew,

So the good news is that everything works as expected. The bad news (for me) is that I need to make sure I update the cookbook to make it clearer. To be blunt, I've not made the cookbook clear enough.

See my comments in-line for explanations of what's happening...

Happy to answer any more questions you might have as a result...

On 6 July 2011 17:00, Matthew <matthew....@gmail.com> wrote:

Thanks, Nicholas. I actually did reset my password before posting,
just to be on the safe side, and got the same results. I'm on the
"create a namespace" portion of the cookbook.

Here is what I receive as the anonymous user:

>>> headers, response = fluidinfo.call('POST', '/namespaces/test', {'name':'childNamespace', 'description':'This is an example.'})
>>> headers
{'status': '401', 'x-fluiddb-path': 'create', 'transfer-encoding':
'chunked', 'content-type': 'text/html', 'x-fluiddb-request-id':
'vnpfrhtkroudaebi', 'server': 'nginx/0.7.65', 'x-fluiddb-action':
'namespaces', 'connection': 'keep-alive', 'date': 'Wed, 06 Jul 2011
15:51:40 GMT', 'x-fluiddb-error-class': 'TPathPermissionDenied', 'x-
fluiddb-category': 'test'}
>>> response
''

This is as expected. The anonymous user doesn't have the privileges needed to create a new namespace under the "test" namespace.

 

And here is what I receive logged in:

>>> fluidinfo.login('matthew', XXXXX)
>>> headers, response = fluidinfo.call('POST', '/namespaces/test', {'name':'childNamespace', 'description':'This is an example.'})
>>> headers
{'status': '401', 'x-fluiddb-path': 'create', 'transfer-encoding':
'chunked', 'content-type': 'text/html', 'x-fluiddb-request-id':
'fvgkleyateyzbjxt', 'server': 'nginx/0.7.65', 'x-fluiddb-action':
'namespaces', 'connection': 'keep-alive', 'date': 'Wed, 06 Jul 2011
15:54:23 GMT', 'x-fluiddb-error-class': 'TPathPermissionDenied', 'x-
fluiddb-category': 'test'}
>>> response
''

This is also as expected! *You* don't have permission to create a new namespace under the "test" namespace. However, if you used the endpoint '/namespaces/matthew' (which is *your* top-level namespace) then it will work! Actually, this is what you do next... :-)

 

I also tried for my own name as the namespace. This worked in Prod,
but no in the Sandbox.

Correct, only a few users have accounts in the sandbox (mainly our alpha testers and client library writers). I'm more than happy to set you up with a username/password on the sandbox - just drop me a line. Nevertheless, it's very easy to delete namespaces, tags and values in the main instance in case you make a mess. :-) 

 

Prod:

>>> headers, response = fluidinfo.call('POST', '/namespaces/matthew', {'name':'childNamespace', 'description':'This is an example.'})
>>> headers
{'status': '201', 'content-length': '120', 'server': 'nginx/0.7.65',
'connection': 'keep-alive', 'location': 'https://fluiddb.fluidinfo.com/
namespaces/matthew/childNamespace', 'cache-control': 'no-cache',
'date': 'Wed, 06 Jul 2011 15:56:41 GMT', 'content-type': 'application/
json'}
>>> response
{u'id': u'2ec5e4bf-2c30-4232-89d2-10726bf40cae', u'URI': u'https://
fluiddb.fluidinfo.com/namespaces/matthew/childNamespace'}

Sandbox:

>>> headers, response = fluidinfo.call('POST', '/namespaces/matthew', {'name':'childNamespace', 'description':'This is an example.'})
>>> headers

{'status': '401', 'content-length': '12', 'server': 'nginx/0.7.65',

'connection': 'keep-alive', 'date': 'Wed, 06 Jul 2011 15:57:41 GMT',

'content-type': 'text/html', 'www-authenticate': 'basic
realm="fluidinfo.com"'}

>>> response
'Unauthorized'
>>>

I would love to be able to play in the Sandbox first (of course :)
while I learn before adding too many objects, etc. to my Prod
environment.

Well, in some sense the objects are only valuable to you once you've tagged them. If you stop tagging them then they're just "orphaned" in some sense unless someone else starts to tag information to them. Part of Fluidinfo's secret sauce is that all objects are shared and openly writeable (and there millions in the main instance, whereas the sandbox is only a minimal test set-up). 

My advice would be to encourage you to just jump in on the main instance. If you have any problems please don't hesitate to email the list or ping us on the fluidinfo channel on freenode IRC.

 

Let me know if you need any more details.

Thanks,
Matthew

Enjoy Fluidinfo! If you have any feedback (both good and bad) please don't hesitate to tell us!

[Matthew]

Thank you for your prompt response, Nicholas!

Just so I'm clear: all items are able to be deleted EXCEPT objects,
right?

And out of curiosity, do those orphaned objects (with no tags) ever
get garbage collected? If they have no tags, they're not very useful,
right?

Thanks again,
Matthew

On Jul 6, 12:20 pm, Nicholas Tollervey <ntoller...@gmail.com> wrote:
> Hi Matthew,
>
> So the good news is that everything works as expected. The bad news (for me)
> is that I need to make sure I update the cookbook to make it clearer. To be
> blunt, I've not made the cookbook clear enough.
>
> See my comments in-line for explanations of what's happening...
>
> Happy to answer any more questions you might have as a result...
>

> > > visithttps://fluidinfo.com/accounts/password_reset/toreset your

[John Chandler]

On 06/07/2011 19:36, Matthew wrote:
> And out of curiosity, do those orphaned objects (with no tags) ever
> get garbage collected? If they have no tags, they're not very useful,
> right?

Not without tags, but they might become useful in the future if someone
adds a tag to them. The orphaned/discarded could be important for
someone else (even objects created by mistake) - you never know :-)

John

[Nick Radcliffe]

Right. I think the other point at the moment is that once an object
has been instantiated, there is either an association between its ID
and its about tag (if it has one) or an establishment that this ID is
not associated with an about tag. Since that relationship is
supposed to be immutable, the object serves as a useful record of the
association (or non-association).

If/when about tags and IDs become unified, this will no longer be an
issue.

Regards

Nick Radcliffe