Im trying to understand the data flow of ejabberd and having a hard time till now.
First, these are the modules Im working on:
ejabberd_c2s, ejabberd_auth, ejabberd_sm, ejabberd_sm_mnesia.
I understand that ejabberd_c2s is a gen_fsm that is entry point for any client that wants to talk to any other client.
Dataflow: When a client connects to ejabberd_c2s, it sends some data, not sure exactly what but along the lines of {JID}. But not able to figure out how ejabberd_c2s authenticates? Where does it actually call the authentication module and if the authentication is successful, who creates a session for that user? is it ejabberd_c2s or ejabberd_auth ?
I understand that ejabberd_sm[_mnesia] are the api calls that will actually create a session for anyone.
References to code/ samples is highly appreciated.!
How exactly this whole thing works?
Thanks a lot!
Authentication is primarily made is wait_for_stream function of c2s: https://github.com/processone/ejabberd/blob/master/src/ejabberd_c2s.erl#L348
Session is created in wait_for_bind function of c2s:
https://github.com/processone/ejabberd/blob/master/src/ejabberd_c2s.erl#L1046
Related
i know this is a question that has been asked many time. but im still concerned about best practice when trying to develop secure code in meteor.
i know you can prevent the client from being able to access the database with the command:
meteor remove insecure
my code currently adds, retrieves records by using Meteor.methods() so although the client is not able to insert data into a collection, it can use the Meteor.method() function. im concerned about holding the login details in the database because would this not mean that the client can use the Meteor.method() function to add/get/remove data from the database.
the client being able to call the Meteor.methods() function seems to still keep the same risk doesn't it? or have i coded me work wrong?
if it help, here is a run down of what my work is doing:
application loads
client calls to get username and password from database
client sends login details to external server (over https) to initiate socket.io connection.
step 2 is the risk because it seems to allow the client to get the login details. once it has this, it uses the socket.io.js library and the api to my webservice to login. so meteor remove insecure doesnt seem to have secured it because get methods are still available in the Meteor.methods()?
being able to use these functions are quite crucial to retrieving data from the database, is there a way around this? what would be best practice for communicating to the database without exposing private data to the client?
Meteor's insecure package is just a tool provided by MDG to quickly prototype apps. It is not meant to be runned in a production app and some people think is a best practise to remove it all together from the start.
After you remove this package, if you want to interact with the database on the client using mini-mongo you must create the appropiate allow and deny rules on the collection. Here is the link for the Meteor documentation on this topic. The other way to interact with the database, is as you said, using Meteor.methods().
Meteor methods calls don't trigger allow or deny rules, since they are runned on the server. You must hardwire all the security measures you need on the Meteor Call by yourself. So it can be a security problem if you don't take the time to secure the call.
Regarding authenticating your clients I would suggest you take a look at Meteor's Accounts package. For example you can add this two packages for basic username/password authentication:
meteor add accounts-base accounts-passwords
Then you can just use the methods detailed on the Meteor Documentation.
I hope this helps.
Login
If you are using accounts-password, you can check the source here to see details of how it works. But here's a rough overview of it. When you call Meteor.loginWithPassword, the password is hashed client-side. Then a method is called with the parameters. The password is then salted and checked against the database server-side. If it matches, the client gets logged in. The client then subscribes to their own user data (Meteor.user()). The server only publishes their data. So everyone else's data is save.
Methods
A method executes code server-side. So they are generally secure. But you can of course write insecure methods. Just know, that you can't trust the parameters passed by the user.
Any tips on how to accomplish the following would be appreciated:
Application A needs to call a SOAP web service (Application B) for a given user. Application A has authenticated the user using our own internal web security processes and knows the ID of the user. Application B requires a user ID and a Kerberos ticket to be passed to it. Can Application A retrieve a ticket from the KDC on behalf of the user to pass along to Application B?
I've been reading a lot about Constrained Delegation, S4U proxies, etc. but am not getting anywhere. This is running in Java 1.6. I'm thinking I need to use JAAS and GSS-API. Has anyone done something like this that could provide insight? I'm not even sure if the setup in Active Directory is correct.
Thank you in advance.
Stanford WebAuth is capable of handling this kind of delegation. It may not map very well into your application, but it at least shows what is possible.
https://github.com/Stanford/webauth
and might give you some hints.
I am using django allauth in a variety of application that i make and its awesome!
Right now, I am trying to develop a login process in two separate steps.
I have a client(mobile) social login with some provider(twitter, Facebook) and the client takes the oauth credentials and sends them back to the server.
That means, that i do not need to use the forms and the templates provided, since all that are handled just fine by the client already.
What i need, is to know what functions/views i need to call in order to avoid all the functions that need the request to work properly.
I hope that i explained in detail my issue.
Thank you in advance,
Michael.
I'm currently trying to setup FOSOAuthServerBundle with my Symfony2 app.
Everything seems to be setup and functional, anyway I'm stuck after the installation.
What is the proper workflow with URLs to get the access_token ?
I tried /oauth/v2/auth, but sounds like I need to define a Client object first.
How to create/generate Client ? Clients are always supposed to be created manually ?
FOSOAuthServerBundle doc is great, but seems to skip all the usage workflow. Am I supposed to check the OAuth2 doc for this ?
Thanks !
In short, yes. You should be using the oAuth2 RFC to determine which workflow you want to use. In regards to client registration the RFC specifically states that the means through which a client registers is beyond the scope of the specification (https://www.rfc-editor.org/rfc/rfc6749#section-2).
With that being said I can give you some insight into how I did this. My application is a mobile phone application that connects to several services running on various servers. I'm also using the Resource Owner Password Credentials Grant.
The way I approached this was: when the application loads, the first thing it does is to check if it has an oAuth2 client id. If it doesn't, then it POSTS to a create client endpoint I've setted up with the meta-data I need. The endpoint validates the POST, creates the client and returns the client information. The application stores the client id and the process doesn't have to be repeated the next time.
Application loads;
Application checks for oAuth2 client id;
If there is one, the process ends;
If there isn't, it posts to http://www.example.com/client;
If we get a 200, store the oAuth2 client id.
I could have also created the oAuth2 client when the user created an account in the application, but I wanted to make the registration process as fast as possible. Creating the client would have added some extra waiting time to the process.
Check this: http://blog.logicexception.com/2012/04/securing-syfmony2-rest-service-wiith.html
It's quite simple to convert to Doctrine, whether you use it.
There's a command-line that does exactly what you need: create a Client!
It seems that basic functionality such as user login, can not be done in simple manner: to have username and password field in form on client and based on that to create store.readPathAccess model access rights. Also, how to check if user is logged in to implement access rights on routes?
Based on examples and (poor) DerbyJS documentation, if I understood it correctly, you have to implement login in server module (lib/server/*) because:
store.readPathAccess must be used in server side
you want to store data in model session (which can be read only on server side)
But many questions arise:
if it has to be done on server side, how to get and store client form data on server side without having problem with second item below on the list (I have done it with manually submitting data to server-only route, but can not then save it in model with local key because I have to redirect to client route after that and local model data is lost)
how to read later that data if it must be stored in session?
even if the store access rights for model is managed, how to check if this specific user is logged in when in client routes?
I'm quite confused at the moment... liked Derby principles, but this authentication problems are playing with my nerves seriously.
I know I may not be quite clear, but there are many points to go in details and if anyone can help I'll gladly give more required info.
Thank you,
Eddie
I found this library today called derby-auth.
It uses passport for signing in and has a good example using a simple register and login form.
What it does is to set some routes on the server for logging the user, and a middleware to tell the client if it's logged or not.
It does have some bugs (a few callback calls missing that break some things), so i wrote my own based on that, but must clean a lot of things before uploading anywhere.
i'd be glad to send it to you if you want to, though.
The most current library is https://github.com/derbyparty/derby-login
It has been updated pretty regularly and works with derbyjs 0.6