Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to link from html form an external php file login?

23 views
Skip to first unread message

^Bart

unread,
Jan 4, 2020, 10:41:40 AM1/4/20
to
Hi guys,

I have this code in my html page:

<body>
<div id="login">
<form method="post" action="" name="login">
<div class="topnav" align="center">
<input type="text" name="usernameEmail" autocomplete="off"
placeholder="Email or Username"/>
<input type="password" name="password" autocomplete="off"
placeholder="Password"/>
<input type="submit" class="button" name="loginSubmit" value="Login">
<a href="#register">Sign Up</a>
<div class="errorMsg"><?php echo $errorMsgLogin; ?></div>
</form>
</div>
</body>

Now I have also php code above in the same file but I'd like to save php
code in an external file named for example login.php but I don't
understand what I should add in the html form to link it to the php's
file :\

Regards.
^Bart

Jerry Stuckle

unread,
Jan 4, 2020, 12:02:11 PM1/4/20
to
<?php require_once(xxxix); ?>

Where 'xxxix' is the location of your login.PHP file. Assuming your
file is in the directory 'include' which is one level BELOW your
server's document root this can be (in decreasing order of recommendation):

1. a path relative to your server's document root, i.e.
$_SERVER['DOCUMENT_ROOT' . '/../include/login.php'
2. a full path, i.e. '/var/www/include/login.php'
3. a path relative to your html file, i.e. '../include/login.php'

Your html would have to have a .php extension.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

J.O. Aho

unread,
Jan 4, 2020, 12:02:58 PM1/4/20
to
Then use other ways to communicate, for example you can use ajax, so the
login form calls your login.php file, the login.php responses with a
status of the login attempt and your javascript will display the error
message or redirect to the next page if the login was correct.

--

//Aho

Ben Bacarisse

unread,
Jan 4, 2020, 12:03:07 PM1/4/20
to
^Bart <gabriel...@hotmail.com> writes:

> Hi guys,
>
> I have this code in my html page:
>
> <body>
> <div id="login">
> <form method="post" action="" name="login">
> <div class="topnav" align="center">
> <input type="text" name="usernameEmail" autocomplete="off" placeholder="Email or Username"/>
> <input type="password" name="password" autocomplete="off" placeholder="Password"/>
> <input type="submit" class="button" name="loginSubmit" value="Login">
> <a href="#register">Sign Up</a>
> <div class="errorMsg"><?php echo $errorMsgLogin; ?></div>
> </form>
> </div>
> </body>
>
> Now I have also php code above in the same file

You mean, I think, some more PHP code that you have not shown us because
there is some in the text you posted!

> but I'd like to save php code in an external file named for example
> login.php but I don't understand what I should add in the html form to
> link it to the php's file :\

PHP code is often "included" or "required" like this:

<?php include 'login.php' ?>

(read the documentation for include and require first, please).

However, this may not be what you are talking about at all, and I have a
feeling you are heading at full speed towards implementing another
unsafe login mechanism. What's the motivation here? Is this a college
exercise?

--
Ben.

^Bart

unread,
Jan 11, 2020, 7:14:43 AM1/11/20
to
> <?php require_once(xxxix); ?>
>
> Where 'xxxix' is the location of your login.PHP file.  Assuming your
> file is in the directory 'include' which is one level BELOW your
> server's document root this can be (in decreasing order of recommendation):

Ok!

> Your html would have to have a .php extension.

But... some shared servers point to index.html so I'd like to have a
*.html file where I'd like to link an external *.php file...

^Bart

Jerry Stuckle

unread,
Jan 11, 2020, 10:45:39 AM1/11/20
to
On 1/11/2020 7:48 AM, Tim Streater wrote:
> In article <qvce7b$c19$1...@gioia.aioe.org>, ^Bart
> You have to tell the server you want to include some PHP, and have that
> PHP file be processed by the server. Depending on hw your server is
> configured, this is often done by using a different extension on the
> html file, such as .php or .phtml.
>

Most shared servers will also allow index.php - if they don't you should
find another hosting company - one that knows what they're doing.

The hosting company (not you) *can* configure the host to parse .html
files as php code - but if I saw a hosting company do that I would run
as fast as I could. It is a security risk as well as a performance
problem because every page will be parsed for php code, whether it
should be or not.

Lew Pitcher

unread,
Jan 11, 2020, 11:04:37 AM1/11/20
to
Put your php into another file (say "login.php") accessable as a URL, then
change
<form method="post" action="" name="login">
to
<form method="post" action="login.php" name="login">
which will direct the form's POST to the "login.php" URL


--
Lew Pitcher
"In Skills, We Trust"

Lew Pitcher

unread,
Jan 11, 2020, 11:53:00 AM1/11/20
to
For those servers, if you cannot change them to point directly at index.php,
you could always change those index.html files to read something like
<html>
<head><meta http-equiv="refresh" content="0,url=index.php" /><head>
<body>Please stand by while we direct you to the login page</body>
</html>
which should immediately cause the browser to GET "index.php" once it
retrieves "index.html".

Note that you can vary the target URL to point to any page, including
"login.php".

Lew Pitcher

unread,
Jan 11, 2020, 11:54:48 AM1/11/20
to
Lew Pitcher wrote:

> ^Bart wrote:
>
>>> <?php require_once(xxxix); ?>
>>>
>>> Where 'xxxix' is the location of your login.PHP file. Assuming your
>>> file is in the directory 'include' which is one level BELOW your
>>> server's document root this can be (in decreasing order of
>>> recommendation):
>>
>> Ok!
>>
>>> Your html would have to have a .php extension.
>>
>> But... some shared servers point to index.html so I'd like to have a
>> *.html file where I'd like to link an external *.php file...
>
> For those servers, if you cannot change them to point directly at
> index.php, you could always change those index.html files to read
> something like

Correction...

> <html>
> <head><meta http-equiv="refresh" content="0,url=index.php" /><head>

That should be
<head><meta http-equiv="refresh" content="0;url=index.php" /><head>
Note the semicolon dividing the refresh time and the target url

Arno Welzel

unread,
Jan 11, 2020, 12:52:58 PM1/11/20
to
^Bart:

> I have this code in my html page:
>
> <body>
> <div id="login">
> <form method="post" action="" name="login">
[...]
> Now I have also php code above in the same file but I'd like to save php
> code in an external file named for example login.php but I don't
> understand what I should add in the html form to link it to the php's
> file :\

I advise you to first learn the basics of HTML, PHP and how web servers
work before you try to create anything which is available to the public.

--
Arno Welzel
https://arnowelzel.de

Pierre Jelenc

unread,
Jan 11, 2020, 5:23:19 PM1/11/20
to
In article <qvcqip$6bl$1...@jstuckle.eternal-september.org>,
Jerry Stuckle <jstu...@attglobal.net> wrote:
>
>The hosting company (not you) *can* configure the host to parse .html
>files as php code - but if I saw a hosting company do that I would run
>as fast as I could. It is a security risk

Why is that?

> as well as a performance
>problem because every page will be parsed for php code, whether it
>should be or not.

Except if every page has PHP scripts anyway...

Pierre
--
Pierre Jelenc
The Gigometer www.gigometer.com
The NYC Beer Guide www.nycbeer.org

Jerry Stuckle

unread,
Jan 11, 2020, 6:14:09 PM1/11/20
to
On 1/11/2020 5:23 PM, Pierre Jelenc wrote:
> In article <qvcqip$6bl$1...@jstuckle.eternal-september.org>,
> Jerry Stuckle <jstu...@attglobal.net> wrote:
>>
>> The hosting company (not you) *can* configure the host to parse .html
>> files as php code - but if I saw a hosting company do that I would run
>> as fast as I could. It is a security risk
>
> Why is that?
>
>> as well as a performance
>> problem because every page will be parsed for php code, whether it
>> should be or not.
>
> Except if every page has PHP scripts anyway...
>
> Pierre
>

Then each page should have a .php extension. Parsing .html files as php
code is still a huge security exposure. And any decent sized site will
have pages that don't contain any php code. TOC and privacy statement
pages come to mind for a start. So do About Us and other common pages.

And that's just the start.

^Bart

unread,
Jan 11, 2020, 6:45:43 PM1/11/20
to
> Correction...
>
>> <html>
>> <head><meta http-equiv="refresh" content="0,url=index.php" /><head>
>
> That should be
> <head><meta http-equiv="refresh" content="0;url=index.php" /><head>
> Note the semicolon dividing the refresh time and the target url
>
>> <body>Please stand by while we direct you to the login page</body>
>> </html>
>> which should immediately cause the browser to GET "index.php" once it
>> retrieves "index.html".
>>
>> Note that you can vary the target URL to point to any page, including
>> "login.php".

Thanks! :)

^Bart

Pierre Jelenc

unread,
Jan 11, 2020, 7:26:43 PM1/11/20
to
In article <qvdkrp$eq7$1...@jstuckle.eternal-september.org>,
Jerry Stuckle <jstu...@attglobal.net> wrote:
>On 1/11/2020 5:23 PM, Pierre Jelenc wrote:
>> In article <qvcqip$6bl$1...@jstuckle.eternal-september.org>,
>> Jerry Stuckle <jstu...@attglobal.net> wrote:
>>>
>>> The hosting company (not you) *can* configure the host to parse .html
>>> files as php code - but if I saw a hosting company do that I would run
>>> as fast as I could. It is a security risk
>>
>> Why is that?
>>
>>> as well as a performance
>>> problem because every page will be parsed for php code, whether it
>>> should be or not.
>>
>> Except if every page has PHP scripts anyway...
>>
>> Pierre
>>
>
>Then each page should have a .php extension. Parsing .html files as php
>code is still a huge security exposure.

But why? I understand that poorly-written PHP is a risk, but that's
independent of the file extension.

> And any decent sized site will have pages that don't contain any php
>code.

Not all sites are large, though.

> TOC and privacy statement pages come to mind for a start. So do
>About Us and other common pages.

Unless they all contain common elements, that are conveniently inserted
via include, require, auto-prepend, auto-append, and the like. Sure, it's
wasting a few cpu cycles and file overheads, but that's not much a problem
with modern hardware, while it makes maintenance far easier when there's
only one file to edit instead of 20. Any site with a menu will benefit
from needing to edit a single included file.

Of course there's SSI, but that does not allow tweaking the include on the
fly, such as highlighting the name the page currently loaded and disabling
its link in the menu.

Jerry Stuckle

unread,
Jan 11, 2020, 11:10:08 PM1/11/20
to
On 1/11/2020 7:26 PM, Pierre Jelenc wrote:
> In article <qvdkrp$eq7$1...@jstuckle.eternal-september.org>,
> Jerry Stuckle <jstu...@attglobal.net> wrote:
>> On 1/11/2020 5:23 PM, Pierre Jelenc wrote:
>>> In article <qvcqip$6bl$1...@jstuckle.eternal-september.org>,
>>> Jerry Stuckle <jstu...@attglobal.net> wrote:
>>>>
>>>> The hosting company (not you) *can* configure the host to parse .html
>>>> files as php code - but if I saw a hosting company do that I would run
>>>> as fast as I could. It is a security risk
>>>
>>> Why is that?
>>>
>>>> as well as a performance
>>>> problem because every page will be parsed for php code, whether it
>>>> should be or not.
>>>
>>> Except if every page has PHP scripts anyway...
>>>
>>> Pierre
>>>
>>
>> Then each page should have a .php extension. Parsing .html files as php
>> code is still a huge security exposure.
>
> But why? I understand that poorly-written PHP is a risk, but that's
> independent of the file extension.
>

Because a .php extension says there might (and probably is) executable
code in it, while a .html extension does not. This makes it much easier
to sneak bad code onto a site because people don't think to look for it
in .html code - especially if it's a static page.

>> And any decent sized site will have pages that don't contain any php
>> code.
>
> Not all sites are large, though.
>
>> TOC and privacy statement pages come to mind for a start. So do
>> About Us and other common pages.
>
> Unless they all contain common elements, that are conveniently inserted
> via include, require, auto-prepend, auto-append, and the like. Sure, it's
> wasting a few cpu cycles and file overheads, but that's not much a problem
> with modern hardware, while it makes maintenance far easier when there's
> only one file to edit instead of 20. Any site with a menu will benefit
> from needing to edit a single included file.

> Of course there's SSI, but that does not allow tweaking the include on the
> fly, such as highlighting the name the page currently loaded and disabling
> its link in the menu.
>
> Pierre
>

Actually, it's quite easy to do both of those with a bit of javascript.
Once again no PHP required.

Jerry Stuckle

unread,
Jan 11, 2020, 11:13:08 PM1/11/20
to
(Sent to quickly)

As to the performance hit - it can be quite significant on a shared
server where you might have 150+ sites all running on the same system.
And that makes it even more critical to NOT parse .html pages as php
code because you don't know what the other sites are doing.

There is a reason that Apache does not parse executable files - php,
perl, python or any others server side languages by default. These guys
know what they're doing.

Jerry Stuckle

unread,
Jan 11, 2020, 11:16:01 PM1/11/20
to
On Apache you can do it even easier in your .htaccess file, but that's
off topic for this group.

Pierre Jelenc

unread,
Jan 12, 2020, 4:21:54 PM1/12/20
to
In article <qve66n$vgo$1...@jstuckle.eternal-september.org>,
Jerry Stuckle <jstu...@attglobal.net> wrote:
>
>Actually, it's quite easy to do both of those with a bit of javascript.
>Once again no PHP required.

Whoa! I'll take PHP anytime over Javascript!

Jerry Stuckle

unread,
Jan 12, 2020, 10:06:38 PM1/12/20
to
On 1/12/2020 4:21 PM, Pierre Jelenc wrote:
> In article <qve66n$vgo$1...@jstuckle.eternal-september.org>,
> Jerry Stuckle <jstu...@attglobal.net> wrote:
>>
>> Actually, it's quite easy to do both of those with a bit of javascript.
>> Once again no PHP required.
>
> Whoa! I'll take PHP anytime over Javascript!
>
> Pierre
>

Javascript has a lot of advantages - among them not being able to
corrupt the server and offloading code onto the client. Many other
things you can't do with PHP.

I use both - each where it is appropriate.

Pierre Jelenc

unread,
Jan 14, 2020, 5:07:51 PM1/14/20
to
In article <qvgmro$k1e$1...@jstuckle.eternal-september.org>,
Jerry Stuckle <jstu...@attglobal.net> wrote:
>
>Javascript has a lot of advantages - among them not being able to
>corrupt the server and offloading code onto the client. Many other
>things you can't do with PHP.

From the client's POV, offloading code onto it is a major inconvenience,
and is the source of just about 100% of the malware and spyware currently
making the rounds (not enough to trigger Flash nostalgia, perhaps, but
still...) while the ability to corrupt is inherent to any badly written
code that runs on the server, regardless of the language.

>I use both - each where it is appropriate.

So do I, but I always get grumpy when it is JS.

Jerry Stuckle

unread,
Jan 15, 2020, 10:40:36 AM1/15/20
to
On 1/14/2020 5:07 PM, Pierre Jelenc wrote:
> In article <qvgmro$k1e$1...@jstuckle.eternal-september.org>,
> Jerry Stuckle <jstu...@attglobal.net> wrote:
>>
>> Javascript has a lot of advantages - among them not being able to
>> corrupt the server and offloading code onto the client. Many other
>> things you can't do with PHP.
>
> From the client's POV, offloading code onto it is a major inconvenience,
> and is the source of just about 100% of the malware and spyware currently
> making the rounds (not enough to trigger Flash nostalgia, perhaps, but
> still...) while the ability to corrupt is inherent to any badly written
> code that runs on the server, regardless of the language.
>
>> I use both - each where it is appropriate.
>
> So do I, but I always get grumpy when it is JS.
>
> Pierre
>

From the client's POV the ability for javascript to create an
interactive experience without having to constantly communicate with the
server is a definite plus. And the amount of code executed on the
client is very minor - and virtually undetectable with today's computers
unless it is really poor code.

Plus javascript has had holes in the code before, but those have been
pretty well identified and closed. The possibility of corrupting
anything on the client's machine is minor.

Additionally, some sites allow users to upload their own pages. But
these are restricted - only static pages allowed with no executable
code. .html pages are allowed but .php, .pl and similar are not.

Any security expert will tell you that you don't want to parse static
pages for php or any other executable code. It is a huge security exposure.

But if you don't care about the security of your site or other sites
running on the server, have at it!

Arno Welzel

unread,
Jan 15, 2020, 2:20:39 PM1/15/20
to
Jerry Stuckle:

> On 1/14/2020 5:07 PM, Pierre Jelenc wrote:
[...]
>> From the client's POV, offloading code onto it is a major inconvenience,
>> and is the source of just about 100% of the malware and spyware currently
>> making the rounds (not enough to trigger Flash nostalgia, perhaps, but
>> still...) while the ability to corrupt is inherent to any badly written
>> code that runs on the server, regardless of the language.
>>
>>> I use both - each where it is appropriate.
>>
>> So do I, but I always get grumpy when it is JS.
>>
>> Pierre
>>
>
> From the client's POV the ability for javascript to create an
> interactive experience without having to constantly communicate with the
> server is a definite plus. And the amount of code executed on the
> client is very minor - and virtually undetectable with today's computers
> unless it is really poor code.

+1

> Plus javascript has had holes in the code before, but those have been
> pretty well identified and closed. The possibility of corrupting
> anything on the client's machine is minor.

+1

And client side scripting is not what is was 10 years ago. We now also
have HTML5 with canvas and WebGL, WebAssembly and web sockets and you
get full featured office applications in the browser:

<https://www.onlyoffice.com/de/integration-demo.aspx>

And this also works very good in Nextcloud, which also uses client side
scripting a lot even though it uses PHP on the server side. This makes
collaborative live editors possible which just did not exist in the past.

In fact browsers became a universal application plattform.

kristja...@gmail.com

unread,
Jan 26, 2020, 11:17:14 PM1/26/20
to
Personally I think, you should have made a little bit research on this topic, before asking....This is the PHP worlds most simple problem in my opinion.


With the best wishes,
Kristjan Robam
0 new messages