I have an auth resource in my library that is correctly returning one of the various statuses based on whether or not the user exists, wrong password, or correct password. I'm trying to get the identity into my controllers though. So in the auth resource I return the status along with user. What needs to happen in my controllers then? I've already handled logging in and redirecting to a different controller. I'm trying to do something like $this->auth->authenticate() and $this->auth->getIdentity() to make sure that they are already authenticated and that they have an identity. What do I need to do so that the identity gets passed around to all of the controllers that I call auth in predispatch?
Also, is there something in Zend Auth that keeps track of how many attempts at logging in have been made?
If use stored the indentiy with Zend_Auth you can get it everywhere you want with:
Zend_Auth::getInstance()->getIdentity()
see also Matthews Tutorial on Zend_Auth
Accessing the Zend_Auth singleton will work, but if you want to get the exact values returned by your resource, put something like this in your controller:
$auth = $this->getInvokeArg('bootstrap')->auth;
Related
I've only used Laravel's Requests for POST methods. In the documentation, all examples use POST methods, but the class does offer a method to check which HTTP verb is used.
Is it advisable to use a Request when the method is GET if there is a need to validate a query, path, or authorize a user? If I were to use requests for GET methods (specifically to authorize a user), what would be the point of using auth middleware?
I believe you are mixing 2 different terminologies together.
First of all, you must not use GET method to authorize anyone. That is totally against the law... (Unless you really want to tamper your user's privacy etc.)
Secondly, Using POST and GET methods is simply your decision. For purposes like, Authenticating users, or say making payments etc, you must make a POST request, but for purposes like Search, Pagination or Verification By Token... GET method must be preferred.
Using Laravel's Route method, you can pass as many parameters as you want to a function and not use GET method at all.
To simply put this, using either is totally your call.
Lastly, Auth Middleware is used for checking if the user who is accessing that page has a session active or not. If you login someone, you call the Laravel's auth()->login() method, which makes a session for that particular user and you can thereby get that user's info on any other view/method by auth()->user() as long as he/she is logged in. If you want, you can make your own middleware and check from the GET requests if the user's email and password are valid or not, you can do that well. But then again, like I said, this shouldn't be happening... Let's not mix up things.
I hope I have made your concepts clear and answered your question correctly. Since you've not really explained using examples, I feel this is where you were really getting confused. Please comment if you have any further doubts. :)
If you want to check the permission at your GET request you can use middleware at routes.
You can create many middleware as you want
Example:
Route::get('admin/profile', function () {
//
})->middleware('auth');
I'm building my first Cakephp application, but I'm pulling my hairs over this problem: I need my application (mydomain.com/cake-app) to co-operate with another non-cake php application (mydomain.com/custom-class) on the same server.
Both applications should share authentications and sessions, and I would like Cakephp to handle these.
However, custom-class will need to see who's logged in, and also add/edit users to my cake-app db, either by accessing my User Model, or by calling an setUser action in my UsersController. custom-class does not have access to the cake-app database.
How can I access Cakephp's AuthComponent and my User Model / UsersController from outside the Cakephp framework? What cake files do I need to include in my custom-class in order to accomplish this?
custom-class does not have access to the cake-app database.
The only way is an API then that doesn't require direct DB access. Implement a RESTful API for example that your none-cake app can call.
http://book.cakephp.org/3.0/en/development/rest.html
http://book.cakephp.org/3.0/en/views/json-and-xml-views.html
However, custom-class will need to see who's logged in, and also
add/edit users to my cake-app db, either by accessing my User Model,
or by calling an setUser action in my UsersController.
You'll have to read the cookie then and the cookie needs to require something you can send along with your API request so that the API knows who is asking for what.
You won't be able to simply require() or include() a few files from Cake and it will work, this isn't going to happen because the Auth system is a complete stack, you would have to initialize a request, controller, component collection, auth component and the auth adpater(s). Instead check how Cake writes and reads the Cookie and implement the same way in your custom class. But pay attention, Cake saves the cookie encrypted.
I'm making web app that will be fully based on Ajax requests.
As I understand the only way to achieve that goal is to send identity and password with every Ajax request or am I wrong?
I'd like to use ZfcUser to perform actions connected with register, login and logout but if I'm calling that on server side: $this->getServiceLocator()->get('controllerPluginManager')->get('zfcUserAuthentication')->getAuthService()->getIdentity(); I always receive last logged user.
Is it possible to handle multiple users at once using ZfcUser plugin (or maybe simply Zend 2)?
Can Zfcuser remember in any data structure all users that are actually logged in?
If you are in a controller you can use $this->ZfcUserAuthentication()->getIdentity() to get the identity. If you are anywhere else, use the servicemanager/locator to get 'zfcuser_auth_service' which you then can use to call getIdentity().
The Auth Service will give you the user based on session, so you should never users from another session. Doesn't matter if you use ajax or not.
I've implemented basic RBAC functionality in my application using Yii. There are roles, tasks and operations set up and working fine.
What I'm trying to accomplish is the following: on user login, check if the user is privileged to log in to this certain area of my application. There's a operation assigned to this particular task. The problem, however, is that the preferred method of checking is the user is permitted to use a operation is CWebUser::checkAccess, which isn't available in the login as the Yii login workflow goes like this:
The user provides information needed for authentication.
An identity instance is created with the user-provided information.
Call
IUserIdentity::authenticate to check if the identity is valid.
If
valid, call CWebUser::login to login the user, and Redirect the user
browser to returnUrl.
If not valid, retrieve the error code or
message from the identity instance and display it.
taken from here
The CWebUser instance available globally via Yii::app()->user is not propagated while in the login state, (list items two and three) which makes perfect sense to me. However, in order to call checkAccess I'd need a CWebUser instance. CAuthManager doesn't seem to provide the functionality I need as it is (there's no method for checking if a user has a certain atomic permission (operation) or list all of them).
In my example, the operation needed is mostly always assigned in conjunction with a role, but who knows - somebody might just have access to this one operation of logging in, which is a case I want to cover.
thanks a lot!
CAuthManager has already a checkAccess method, which performs what you need. For more information you can check Yii's official documents:
IAuthManager
I have read several tutorials to introduce myself to know more about the rest API recently. However, I have got some doubts here and there and hope someone can help me out with this.
Reading the Beginner's Guide to HTML and REST, which states:
"Resources are best thought of as nouns. For example, the following is not RESTful: 1 /clients/add This is because it uses a URL to describe an action. This is a fairly fundamental point in distinguishing RESTful from non-RESTful systems."
As such, I was wondering if for such cases where I have a user resource and to access it to do the usual insert/update/delete/retrieve
would be as follow:
www.example.com/users [get] <-- to retrieve all records
www.example.com/users/1 [get] <-- to retrieve record with id of 1
www.example.com/users/1 [put] <-- to update record with id of 1
www.example.com/user/1 [delete] <-- to delete record with id of 1
www.example.com/user [post] <-- to insert a new user record
This would have used up the 4 common verbs to make request.
What if I were to require a function such as login or perhaps in general any other types of action commands? How should the url be formed and how should the router redirect in such cases?
EDIT:
After looking at the various comments and answers. My take away from them is that the final solution would be somewhere along "use rest principles whenever possible and use the query string method with functions whenever not."
However, I was thinking of a slight variant of the implementation (not a restful implementation anymore, but following similar concepts) and wondering if it could have work out this way. Hope you guys can advice me on this.
Using the same authenticate/login function I would require to implement, could it be something along this instead:
www.example.com/users [get] <-- to retrieve all records
www.example.com/users/1 [get] <-- to retrieve record with id of 1
www.example.com/users/1 [put] <-- to update record with id of 1
www.example.com/user/1 [delete] <-- to delete record with id of 1
www.example.com/user [post] <-- to insert a new user record
as usual and if I were to require an action to be performed it will be as such:
[controller]/[action] --- user/authenticate [post] --- to login
[controller]/[id]/[action] --- user/1/authenticate [put] --- to logout
Will this work? Will there be any foreseen problems that I would face and are there similar implementations out there like this already? Please kindly advice!
REST is stateless so you need to put all the needed information into all queries. The idea is to work with the HTTP Verbs (GET, PUT, DELETE, POST - as you already descripted).
If you want an user authentification for your REST API, use something like HTTP Basic Auth, or your own Authentification. You have to send the Auth Information for every Request to the Server (stateless).
If you don't want an HTTP Basic Auth you can try some Token Authentification or any other auth.
Edit: If you want an "Check Login" Resource, build your own.
For Example GET /account/checklogin with http basic auth header informations. The Result of this Request depends on your Authinformations.
There are some actions that are hard to model in a true RESTful way - but login, for instance, can be implemented using the following pseudo code:
GET the user rights whose userID is x and password is y
if (user rights found)
assign rights to current user
else
do not assign rights to user
See this question for how to retrieve the user rights. The point in this question is that you usually need multiple ways of accessing your resources. Some are based on IDs or well-know attributes, for instance:
www.example.com/users/department [get] (get all users for a department)
www.example.com/users/roleName [get] (get all users in a particular role)
www.example.com/users/status/active [get] (get all users who are "active")
However, some ways of accessing users - especially when you need to combine two or more filtering attributes - are easier to manage using query string parameters. For instance:
www.example.com/users?department=xxx&role=yyy&status=active [get]
So, your REST API might expose a URL along the lines of:
www.example.com/users?userName=xxxx&password=yyy [get]
This URL would match the username and password parameters against the user database, and return either a 404 (if they don't match a known user), or a document representing the user, with their access rights.
Your client code then manages the current user's session - i.e. by setting the status to "logged in ", and associating the session with that user profile.
The key to making this work is assigning responsibility to the right layer - the API should not have to manage user sessions, that is the responsibility of the client application. There are cases where that doesn't work particularly well - not sure if yours is one, though.
If you really want to use a POST request, you can, of course, consider the "login" method the start of a session for that user. You could, therefore, do something like this:
www.example.com/session [POST] with parameters userID and password.
This would return a representation of the user profile and rights; it might also create documents accessible under the URLs
www.example.com/session/sessionID
www.example.com/session/user/ID/session
However, in general, it is a very dangerous idea to manage session state within the API - nearly always, you want the client session to be managed by the application interacting with the client, not by the API it talks to.
What if I were to require a function such as login or perhaps in
general any other types of action commands? How should the url be
formed and how should the router redirect in such cases?
It's not RESTful to have a login-action resource, but it is RESTful to provide a login-form resource:
/login-form
The HTML-form you return in the response functions as code-on-demand; you are supplying a configured piece of software to help the user supply their login credentials.
There would be nothing wrong with identifying the resource as just /login - I added the form-part to make the example clear.
You should avoid redirects where auth is required because it breaks the interface for clients other than web-browsers; instead you might either: provide a link to the login-form; or actually supply the login-form code in the response.
If you want to manage authentication, I prefer the approach of creating auth-tokens; in the case of Web-browsers I consider it acceptable to overload a single cookie for the purpose of helping the client supply the token with each request since they will have no other reasonable way to control the Auth header they send; obviously if you're writing your own client-application this is not a concern.
Answering your comments below, the purpose of the login form in an auth-token scenario is to create a new authentication token. So, thinking RESTfully, you model the users list of auth-tokens and POST a representation of the auth-token. This representation might contain the user's username and password. You might let the user choose their own token, or you might choose it for them and return this in the response. There is no action-URI required, and setting any cookies happens following successful creation of the new auth-token.
I recommend studying Amazon S3 REST API. It's slightly different than your requirement but its the best in-depth description of a potential REST authentication system I've seen set out:
http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAPI.html
Your thoughts on managing users RESTfully are accurate.
Hope it helps :)