Laravel 5: How to validate querystring?

Hi

I am using laravel 5.

I have a situation where my url is [QUOTE]http://example.com/gallery/delete/10[/QUOTE]

Where 10 is the id (primary key) of the gallery table.

I want to validate that the gallery id 10 belongs to the logged in user and if so i will delete it. So I am using the following code

    $deleted = Gallery::where('id', $Request->id)->where('user_id', Auth::id())->delete();

Now, the $deleted variable holds the value 0 if the deletion isnt successful and 1 if the deletion was successful.

How do I make laravel show an error message in blade template if the deletion wasnt successful?

1 Like

Try this in your controller

if($deleted == 0){
      Session::flash('flash_message', '<strong>problem in deleting record</strong>');
      return view('your.view.here');
}    

// your view blade template

   @if ( Session::has('flash_message') )
            <div class="row">
    <div class="col-lg-12">
        <h1 class="page-header"></h1>
    </div>
</div>

<div class="alert alert-info " role="alert">
   {!! Session::get('flash_message') !!}
</div>

@endif

2 Likes

Thanks for your reply. Is there anyway i can use blade’s default error variable $errors to show this error?

1 Like

you can put this in your blade.

  @if($errors->any())
      <ul class="alert alert-info">
        @foreach($errors->all() as $error)
            <li>{{ $error }} </li>
  
        @endforeach
      </ul>
   @endif
1 Like

Not directly connected to Laravel but you shouldn’t be using URLs with IDs for deleting anything. The ID should be sent via POST. If you send it via GET then there is a security issue, for example the URL for deleting a record can be stored in the browser history and simply navigating to the page will trigger the delete action. Actions that change data on the server should be invoked with POST and your code should specifically read the ID only from POST.

There is no difference regarding security between $_GET and $_POST as both are easily read and modified. One is more visible than the other but that has nothing to do with security.

Of course there is security difference. This is not security against hackers who, as you said, can easily modify POST or GET, but there is security against unintended triggering of changes on the server. If the delete action is a GET request with an ID then this URL will be stored in browser’s history and possibly in some proxy servers, etc. Then it’s easy for the user to visit their history and unwittingly change or delete something simply by loading a URL or by going back/forward. This can sometimes happen after launching a web browser via session restore mechanisms. POST data is not saved in history therefore the user is safe against such unintended actions. This is one of the reasons why POST should be used for triggering actions that change data while GET should be used for actions that only fetch data.

That isn’t a security matter - it is one of using the correct type of call for what you are trying to do.

A GET call is assumed to be retrieving data and not changing anything. Browsers will often cache the value returned from a GET call in order to avoid needing to call the server again as the value can be assumed to be unchanged from when the previous call was made.

A POST call may update something on the server and so will never have anything cached as a repeat of the same call may be dealing with completely different data on the server.

For more information on how the different HTTP methods are intended (and presumed by browsers and servers) to be used see http://restcookbook.com/HTTP%20Methods/idempotency/

This is a security matter as well. Imagine a banking site that uses GET to accept input data - apart from the fact that this is incorrect type of call this also lessens security because all your banking activity is left in your browser history. Most often GET data is logged while POST data is not - of course there is no guarantee that a web browser will not log POST data (for example, with an extension) but it is an important ingredient of securing your banking activity and making sure that as little trace is left behind as possible. This is important for any other activities so that your posted messages, sent emails via webmail, online forms, etc. are not left in your browser history, your ISP server logs, proxy logs, etc. indefinitely for everyone to see.

Any misuse of something for a purpose for which it isn’t intended becomes a security matter if that is the case.

The simplest way to fix such ‘security matters’ is to use the code intended for the purpose instead of one intended for something else. Then you no longer have that ‘security matter’.

The world is not so black and white - one way of doing something often has many implications, there’s not one and only reason to use POST over GET. Although the main purposes of POST and GET are what you are saying, there are also side effects and one of them is increased security when using POST. Sure, it would be inappropriate to rely solely on POST for security - but then no one in their right mind would use GET for posting forms or deleting records where security is important.

In the same way you could say that using prepared statements is not the right thing for security - because security was never the intended reason for prepared statements. But security is a side effect of prepared statements and it is perfectly fine to use them for this purpose.

Of course, and in this case POST is a much more preferred method from the security standpoint than GET and all properly coded web sites use POST for sending form data that modify stuff on the server in any way.

But we are going off topic here. Whether or not one believes that POST increases security or not the usage of GET for deleting a record is an incorrect type of call for this particular action.

We definitely agree on that.

There is no harm in specifying a resource using uri. Quite contrary, that’s rather a most natural and preferred way.

What you rather have to do is to specify a proper method for the action. Which, for delete, definitely should be POST followed by GET.

I think @phantom007 using the resource controller .

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.