0

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?

Shane
  • 1,190
  • 15
  • 28
  • `Request` is used so you don't have to f*** about with `$_POST`, `$_GET` and other annoying superglobals. It's available regardless of HTTP verb in use. You can retrieve input via `$request->input('key_name');`, regardless of HTTP verb. Since you use a route before you even do anything, why would you validate anything? Using middleware, you can ensure that your controllers are in use only when an authenticated user is accessing them. I think you're overcomplicating something very, very simple. – N.B. Sep 09 '16 at 22:37
  • @N.B. I started thinking about this when I had nested routes. When creating `ChildModel`, I needed to make sure that the logged in user owned `ParentModel`. This created some double-dipping issues where I was getting `ParentModel` in the controller and also the request. That's what got me thinking that I should just use the request's properties and use a request for any method if a model is concerned. – Shane Sep 09 '16 at 22:49
  • I don't see how it relates to `Request` object.. before creating whatever you have to do, create a middleware that will check whether user owns something or not, add it to the route and that's it. `Request` simply exists for encapsulation of the entire http request. You don't have to use it if you don't want to, it's globally available wherever via dependency injector, it's super useful and easy to use so - to answer your actual question - yes, it is advisable to use `Request` every single time you require user input or anything else related to info in HTTP request. – N.B. Sep 09 '16 at 22:53
  • I've been using the requests to make my controller methods cleaner. So, if I was simply viewing `/parents/{parent_id}/children/{child_id}`, I originally had the controller automatically finding these models so I wouldn't have to copy-paste the query in the relevant controller methods. At the same time, for controller methods that were `POST`, I would, by necessity, be querying these models in the request to authorize the user. Instead of doing two queries for the same model, I was thinking of just using the request's query results. The way you described, it seems requests are the way to go. – Shane Sep 09 '16 at 23:06
  • I get the gist of what you're trying to do. Since I'm super lazy by nature, I never actually used Laravel's relationships (except for mass inserts). I always create views in MySQL and have read-only eloquent models that query the view. If I get the result back (something like `MyView::where('parent_id', 1)->where('child_id', 2);` then everything went fine. Using foreign keys, I ensure the data integrity and avoid potential "what if this model doesn't own that". But that's just me I guess :) – N.B. Sep 09 '16 at 23:10

2 Answers2

1

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. :)

prateekkathal
  • 3,482
  • 1
  • 20
  • 40
  • Can you elaborate on how using `GET` is tampering with users' privacy? Where did you read that, or how did you come to that conclusion? Some evidence would be nice. – N.B. Sep 10 '16 at 16:37
  • `GET` doesn't "tamper" with user privacy. `GET` exposes data, and therefore allows people to tamper with security. For example if you allow a user to send your the user and password through `GET` and there is proxy in the network the person with access to the proxy already knows the users and passwords of people using that network. But, instead if you use `POST` and `SSL` with a secure certificate they won't be able to pick on that data. – Nestor Mata Cuthbert Sep 10 '16 at 21:52
  • Another example is if someone uses GET to send user and password from a coffee shop, same thing, anyone in that same network will be able to see your user and password freely. Now you see? **don't authenticate with GET** please! – Nestor Mata Cuthbert Sep 10 '16 at 21:54
  • I'm not authenticating users with get. I'm authorizing logged in users when they try to view the edit page of an owned resource though. – Shane Sep 11 '16 at 19:45
  • Please elaborate **when they try to view the edit page of an owned resource** – prateekkathal Sep 12 '16 at 06:14
  • @prateekkathal A user owns a `Restaurant` model. So, when they `GET /restaurants/{restaurant_id}/edit`, I need to make sure that the `Restaurant` with `restaurant_id` belongs to the user visiting that route. Similarly, a `Restaurant` owns a `Menu`, so when a user visits `GET /restaurants/{restaurant_id}/menus/{menu_id}/edit`, I need to make sure that the user owns the `Restaurant`, and also that the `Menu` belongs to the `Restaurant`. – Shane Sep 12 '16 at 16:00
  • @Shane Sry for the late reply.... To achieve this, you will have to make use Of Laravel Middlewares -> So in the middleware you can check if the `auth()->user()->restaurants()->get()->where('id', $restaurant_id);` ... Something like that... :) Same goes for Menus... You can just add `$menu = Restaurant::find($restaurant_id)->menu()->first(); if($menu->id != $menu_id) return redirect(route('blahblah'));` Did you get it? – prateekkathal Sep 22 '16 at 05:43
0

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');

Thao Ha
  • 1