Use Django authentication from client side DDP Client

[SantoshSrinivas79]

I am trying to integrate a DDP Client into my Django app on the client side as explained here.

I believe from the post, that everything should work fine, except that I want to add an authentication layer for my publish and subscribe calls. Only a "check" for userLoggedIn to determine if the client is authorized to subscribe is enough.

However, I plan to have the user login done through Django and I want to modify the authentication check in Meteor to use the Django authentication system.

Any idea how I can use the DDP "request" from the DDP client to determine if the user has already been authenticated by Django or not.

I am new to DDP and Django (!) and wondering if there are any session type things in the DDP "request" that I can use on the server side to determine if the user has been authenticated by Django already.

I hope I am able to explain it clearly ... Please help!

[codyparker]

So, you aren't using django-ddp to handle the link between them?

I didn't read that full article, but is there a session maintained for each connection on the Django-side? If so, you should be able to just check if the user is authenticated in the normal Django way: request.user.is_authenticated()

Or for the meteor-side, you may find some clues in the accounts app included with django-ddp, which emulates the Meteor auth backend in Django and allows for the authentication to occur there. It then sends back the auth token so in Meteor you can check Meteor.user() for the current user as you normally would.

Not sure if that helps....

[SantoshSrinivas79]

Yes, I don't want to use django-ddp per se. But I thought someone here would be able to help around this question involving django and DDP.

Actually your idea is on the lines of what I am looking for. Is there a way I can pass the "django Request object" when I say subscribe to a Meteor publication.

If I can do that, I can use request.user.is_authenticated() type of thing to figure out the rest. I only need the Django Session and Request object to be passed with the calls from Client Side DDP Client

[codyparker]

OK, so you're going the other way? Like I said, I didn't really read that article. I assumed since this was posted here you were trying to connect a Meteor app to a Django backend.

If the Django app is calling out to Meteor to get data, or post data, could you not just prevent unauthorized users in Django from making the subscription or call?

Obviously, this isn't django-ddp project related, so it may be better to continue this on the Stack Overflow question you posted.

[SantoshSrinivas79]

@tysonclugg would you be able to advise on this question?

[tysonclugg]

First, I recommend that you follow the instructions from the README and use Django DDP as your primary connection. Having your client use Django DDP as a secondary connection forces you to understand and work around any assumptions made in Meteor core (and in many packages) regarding the use of the primary DDP connection.

Login RPC calls are only sent on the "primary" DDP connection, as methods such as Meteor.loginWithPassword are bound to an instance of Accounts that is instantiated with default options, so it binds to the default DDP connection. It is possible to create a new instance of the Accounts object passing {connection: <foo>}, but you will need to call it's login methods directly rather than the usual Meteor.loginWithPassword and such. See http://docs.meteor.com/api/accounts-multi.html for details on how to use authentication across multiple connections.

It is possible to alter the default login behaviour, see https://github.com/tysonclugg/accounts-secure/blob/master/password_client.js for an example of how to replace the default Meteor.loginWithPassword function with your own.

You could of course call the login API endpoint directly, or use some other means of passing authentication through to your Django app.

Once you've achieved any of the above, then this.user_id, this.user in your Django DDP app will refer to the current user (or None if not logged in).

Then there is external service authentication, it may suit your needs or it could be a waste of time - I've not used it.