Pedro Melo

"Hi, Aristochat seems very nice, but did you knew about http://www.speeqe.com/? Same thing, and the source code is available. Best regards," - Pedro Melo

"Hi, AFAIK, the SAPO Messenger project is on hold right now. The main developer is working on other projects inside SAPO. So I wouldn't hold my breath." - Pedro Melo

"Yes, I think the problem you are having stems from the fact that you are using the same thing (tokens) for two different purposes: authentication/identification and users. With your schema, a token maps to a single user. Check back Yuval article. See how he splits Users and Identifications. With that split you can have multiple tokens, a username/password, a OpenID URL, all of those identifiers map to the same user. If you split those, you can evolve your authentication mechanisms without rewriting the model, because from the model point of view, he only deals with Users. For migrations and direct access to the Model, what I do is to create a user just to do the migration. And then my script authenticates to the model with that user. This allows my auditing log to record who created those migration users and when. Best regards," - Pedro Melo

"Hi Sid, Regarding your REST app, there are two things that you need to consider: authentication (given a token, which user are we talking about), and authorization (the authenticated user can do what he is trying to do). The second part, authorization, is easy, and should be in the model. The first is debatable, and in some cases parts of it might be outside the model if they are very specific to a particular technology (for example, using client side certificates in a web browser). In either cases (and check Yuval article that I linked to) the model must know that the token or the certificate belongs to user X. The mapping of "information used to authenticate" => "User X in my model" belongs inside the model. How you obtain "information used to authenticate" might not. In your particular case, tokens, I would put that inside the model because I could have different tokens for the same user with different levels of access. This way, a user of my system, can generate a read-only token..." - Pedro Melo

"I keep some parts of the authentication in the controller. For example, OpenID. It makes total sense to make most of that in the controller because it is very web oriented. After I have the identity of the user validated, I delegate everything else to the model. Which methods can be called by which users, and which roles or permissions the user needs to have to call a specific method belongs inside the model, because all your interfaces with the user (web, email, API, xmpp, sms, whatever) need the same validation. Putting that on the controller means that you are only protecting the calls to the model form the webapp. You would then need to implement the same code in the other channels... I see controllers as a very thin layer than translate web requests into model requests, nothing more. The model contains all the business logic, and at least in our case, the user that is acting on the model is clearly important to validate what can or cannot be done. And so far its been working..." - Pedro Melo

"No, I don't think it is wrong at all. I have a forum system. The model for it makes sure that the authenticated user is the author. With the authenticated user the model can also decide if the user is a moderator or not. The model really benefits from knowing the user. And yes, all my models are usable outside Catalyst. Thats the exact point of making it standalone. I don't depend on the Catalyst request inside my model at all. I don't even use any of the Catalyst auth framework... I don't see how you got to that conclusion from my post, please point it out so that I can explain better. In fact I actually use more and more the Mojolicious framework. My CronJobs and JobServer authenticate them selfs to the model before calling any APIs. As for authentication, some of it is implemented inside the model. Your two examples are indeed implemented inside the model. Some methods, like OpenID are implemented in the Web app, but at the end the Web App performs a authentication saying "the user..." - Pedro Melo