-1

I'm trying to create a basic login system and i'm running into a problem. I learned that you should send form values using the form action to another file that will process the input data.

But the problem is, when an error occurs and I send them back to the register page the values of their input are gone, I could of course place them in a session variable(like I do with the error message) but it just doesn't feel like the correct way.

So my questions is: Why should I use the form action attribute if I can just put the code on the same page and if an error occurs just do value="<?php echo $_POST['username']?>" to make the value show up in the input?

Kind regards.

Bas Grave
  • 1
  • 1
  • 1
    not sure where you *learned that you should send form values to another file*, but thats simply not true. If it suits your usecase and you security it properly, then whats the harm. – DevDonkey Apr 13 '17 at 08:35
  • @DevDonkey I didn't mean like always but I thought it increased security. As for a login system I thought it would be mandatory to use the form action. – Bas Grave Apr 13 '17 at 08:42
  • the security is the same either way.. so long as you sanitise anything coming in you should be good to go – DevDonkey Apr 13 '17 at 08:43

2 Answers2

0

URL !== file! It absolutely makes sense to send the form submission to the same URL since it simplifies the browser behaviour; but you can structure your backend any way you need into different files which will handle this as appropriate. The difference will be that the initial page load will be a GET request, whereas the form submission will be a POST request; in a properly structured backend (and using MVC parlance) those would be handled by different controllers, which will then render the same view though.

A primitive illustration:

switch ($_SERVER['REQUEST_METHOD']) {
    case 'POST':
        require_once 'FormPostController.php';
        (new FormPostController())->handleRequest();
        /* here be dragons */
    case 'GET':
        /* maybe do something */
    default:
        header('HTTP/1.0 405 Method Not Allowed');
        exit;
}

require 'form.html';

You can even make this differentiation at the web server level using rewrite rules which will invoke different .php files for different request methods.

Community
  • 1
  • 1
deceze
  • 510,633
  • 85
  • 743
  • 889
  • I would like to thank you for your answer but this seems a bit to complicated. – Bas Grave Apr 13 '17 at 08:56
  • I understand that a URL isn't necessarily a file, but given the simplicity of the question, it was a fair assumption. Given that the OP is just beginning to grasp the basics, I didn't feel the need to get pedantic about the difference. – Difster Apr 13 '17 at 08:57
  • @Bas Well, what's the argument for separating it into different files? Usually that it makes code more manageable. To make code more manageable you break it down into smaller pieces and then add some boilerplate which puts them together as needed. What I show here is the boilerplate. If your use case is so trivial that even this seems overkill… fine. But in any halfway complex application, this is still much too simplistic. – deceze Apr 13 '17 at 09:03
  • @Difster The thing is that the browser behaves very differently when you send it to a different URL, which creates issues you need to work around. If your only goal is to separate code into different files for better maintainability, then this kind of defeats the purpose. For that it is essential to properly grasp and use the difference between URLs and files. – deceze Apr 13 '17 at 09:05
-1

Using a different file to submit the form to makes for maintainable and reusable code. Sure, you can use the same file and if this one form is all you need, then go ahead.

Otherwise, look in to using AJAX. There are plenty of tutorials out there on AJAX so I won't cite one here.

Difster
  • 3,264
  • 2
  • 22
  • 32
  • I agree with the more maintainable code, I have looked into using AJAX but i found a stack overflow page that said AJAX is kinda obsolete for a login system as you have to redirect them anyway if the login is successful . – Bas Grave Apr 13 '17 at 08:39
  • No, it's not obsolete at all. It's very easy to use and it keeps things consistent throughout your application. For those times when the login fails, and you don't want to redirect, that's where AJAX does so well. Besides that, learning AJAX is a useful skill that applies across a wide range of problems. Why did my answer get marked down? It's a perfectly good answer. – Difster Apr 13 '17 at 08:42
  • I will look into it, what would happen if java script is disabled by the user? I did not mark down your answer. – Bas Grave Apr 13 '17 at 08:47
  • While there is that possibility, the vast majority of websites won't function these days if people disable javascript so very few people that. You could always test for it when the page loads and warn them it won't work properly otherwise. – Difster Apr 13 '17 at 08:54
  • Also, could you give me an up vote to negate whoever decided they didn't like my answer? :) Thanks. – Difster Apr 13 '17 at 08:55
  • OR you could just design your web sites using *progressive enhancement*. Make it work with PHP first, then add JavaScript after everything works. That way, if JavaScript is disabled, your page continues to work - albeit slightly differently than if you had the JS enabled. The reason you got a DV - I am just speculating here - is because what you said is more of a comment than an answer. The question should be closed as primarily opinion based because people will land on either side of the argument, rather than coming up with a fact based answer. – Jay Blanchard Apr 13 '17 at 13:30