Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #18169 > unrolled thread
| Started by | ^Bart <gabriele1NOSPAM@hotmail.com> |
|---|---|
| First post | 2020-01-04 16:41 +0100 |
| Last post | 2020-01-26 20:17 -0800 |
| Articles | 20 on this page of 24 — 9 participants |
Back to article view | Back to comp.lang.php
How to link from html form an external php file login? ^Bart <gabriele1NOSPAM@hotmail.com> - 2020-01-04 16:41 +0100
Re: How to link from html form an external php file login? Jerry Stuckle <jstucklex@attglobal.net> - 2020-01-04 12:02 -0500
Re: How to link from html form an external php file login? ^Bart <gabriele1NOSPAM@hotmail.com> - 2020-01-11 13:14 +0100
Re: How to link from html form an external php file login? Tim Streater <timstreater@greenbee.net> - 2020-01-11 12:48 +0000
Re: How to link from html form an external php file login? Jerry Stuckle <jstucklex@attglobal.net> - 2020-01-11 10:45 -0500
Re: How to link from html form an external php file login? rcpj@panix.com (Pierre Jelenc) - 2020-01-11 22:23 +0000
Re: How to link from html form an external php file login? Jerry Stuckle <jstucklex@attglobal.net> - 2020-01-11 18:14 -0500
Re: How to link from html form an external php file login? rcpj@panix.com (Pierre Jelenc) - 2020-01-12 00:26 +0000
Re: How to link from html form an external php file login? Jerry Stuckle <jstucklex@attglobal.net> - 2020-01-11 23:10 -0500
Re: How to link from html form an external php file login? rcpj@panix.com (Pierre Jelenc) - 2020-01-12 21:21 +0000
Re: How to link from html form an external php file login? Jerry Stuckle <jstucklex@attglobal.net> - 2020-01-12 22:07 -0500
Re: How to link from html form an external php file login? rcpj@panix.com (Pierre Jelenc) - 2020-01-14 22:07 +0000
Re: How to link from html form an external php file login? Jerry Stuckle <jstucklex@attglobal.net> - 2020-01-15 10:40 -0500
Re: How to link from html form an external php file login? Arno Welzel <usenet@arnowelzel.de> - 2020-01-15 20:20 +0100
Re: How to link from html form an external php file login? Jerry Stuckle <jstucklex@attglobal.net> - 2020-01-11 23:13 -0500
Re: How to link from html form an external php file login? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-11 11:52 -0500
Re: How to link from html form an external php file login? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-11 11:54 -0500
Re: How to link from html form an external php file login? ^Bart <gabriele1NOSPAM@hotmail.com> - 2020-01-12 00:45 +0100
Re: How to link from html form an external php file login? Jerry Stuckle <jstucklex@attglobal.net> - 2020-01-11 23:16 -0500
Re: How to link from html form an external php file login? "J.O. Aho" <user@example.net> - 2020-01-04 18:02 +0100
Re: How to link from html form an external php file login? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-04 17:03 +0000
Re: How to link from html form an external php file login? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-11 11:04 -0500
Re: How to link from html form an external php file login? Arno Welzel <usenet@arnowelzel.de> - 2020-01-11 18:52 +0100
Re: How to link from html form an external php file login? kristjanman2k20@gmail.com - 2020-01-26 20:17 -0800
Page 1 of 2 [1] 2 Next page →
| From | ^Bart <gabriele1NOSPAM@hotmail.com> |
|---|---|
| Date | 2020-01-04 16:41 +0100 |
| Subject | How to link from html form an external php file login? |
| Message-ID | <quqbnf$kj9$1@gioia.aioe.org> |
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
[toc] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2020-01-04 12:02 -0500 |
| Message-ID | <quqged$mm5$1@jstuckle.eternal-september.org> |
| In reply to | #18169 |
On 1/4/2020 10:41 AM, ^Bart wrote:
> 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
<?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
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | ^Bart <gabriele1NOSPAM@hotmail.com> |
|---|---|
| Date | 2020-01-11 13:14 +0100 |
| Message-ID | <qvce7b$c19$1@gioia.aioe.org> |
| In reply to | #18170 |
> <?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
[toc] | [prev] | [next] | [standalone]
| From | Tim Streater <timstreater@greenbee.net> |
|---|---|
| Date | 2020-01-11 12:48 +0000 |
| Message-ID | <110120201248384947%timstreater@greenbee.net> |
| In reply to | #18173 |
In article <qvce7b$c19$1@gioia.aioe.org>, ^Bart <gabriele1NOSPAM@hotmail.com> 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... 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. -- I was brought up to believe that you should never give offence if you can avoid it; the new culture tells us you should always take offence if you can. There are now experts in the art of taking offence, indeed whole academic subjects, such as 'gender studies', devoted to it. Roger Scruton
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2020-01-11 10:45 -0500 |
| Message-ID | <qvcqip$6bl$1@jstuckle.eternal-september.org> |
| In reply to | #18174 |
On 1/11/2020 7:48 AM, Tim Streater wrote: > In article <qvce7b$c19$1@gioia.aioe.org>, ^Bart > <gabriele1NOSPAM@hotmail.com> 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... > > 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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | rcpj@panix.com (Pierre Jelenc) |
|---|---|
| Date | 2020-01-11 22:23 +0000 |
| Message-ID | <qvdhsi$ed4$1@reader2.panix.com> |
| In reply to | #18175 |
In article <qvcqip$6bl$1@jstuckle.eternal-september.org>,
Jerry Stuckle <jstucklex@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
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2020-01-11 18:14 -0500 |
| Message-ID | <qvdkrp$eq7$1@jstuckle.eternal-september.org> |
| In reply to | #18180 |
On 1/11/2020 5:23 PM, Pierre Jelenc wrote: > In article <qvcqip$6bl$1@jstuckle.eternal-september.org>, > Jerry Stuckle <jstucklex@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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | rcpj@panix.com (Pierre Jelenc) |
|---|---|
| Date | 2020-01-12 00:26 +0000 |
| Message-ID | <qvdp3u$7dv$1@reader2.panix.com> |
| In reply to | #18181 |
In article <qvdkrp$eq7$1@jstuckle.eternal-september.org>,
Jerry Stuckle <jstucklex@attglobal.net> wrote:
>On 1/11/2020 5:23 PM, Pierre Jelenc wrote:
>> In article <qvcqip$6bl$1@jstuckle.eternal-september.org>,
>> Jerry Stuckle <jstucklex@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.
Pierre
--
Pierre Jelenc
The Gigometer www.gigometer.com
The NYC Beer Guide www.nycbeer.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2020-01-11 23:10 -0500 |
| Message-ID | <qve66n$vgo$1@jstuckle.eternal-september.org> |
| In reply to | #18183 |
On 1/11/2020 7:26 PM, Pierre Jelenc wrote: > In article <qvdkrp$eq7$1@jstuckle.eternal-september.org>, > Jerry Stuckle <jstucklex@attglobal.net> wrote: >> On 1/11/2020 5:23 PM, Pierre Jelenc wrote: >>> In article <qvcqip$6bl$1@jstuckle.eternal-september.org>, >>> Jerry Stuckle <jstucklex@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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | rcpj@panix.com (Pierre Jelenc) |
|---|---|
| Date | 2020-01-12 21:21 +0000 |
| Message-ID | <qvg2ld$8r2$1@reader2.panix.com> |
| In reply to | #18184 |
In article <qve66n$vgo$1@jstuckle.eternal-september.org>,
Jerry Stuckle <jstucklex@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
--
Pierre Jelenc
The Gigometer www.gigometer.com
The NYC Beer Guide www.nycbeer.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2020-01-12 22:07 -0500 |
| Message-ID | <qvgmro$k1e$1@jstuckle.eternal-september.org> |
| In reply to | #18187 |
On 1/12/2020 4:21 PM, Pierre Jelenc wrote: > In article <qve66n$vgo$1@jstuckle.eternal-september.org>, > Jerry Stuckle <jstucklex@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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | rcpj@panix.com (Pierre Jelenc) |
|---|---|
| Date | 2020-01-14 22:07 +0000 |
| Message-ID | <qvle3i$2ee$1@reader2.panix.com> |
| In reply to | #18188 |
In article <qvgmro$k1e$1@jstuckle.eternal-september.org>,
Jerry Stuckle <jstucklex@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
--
Pierre Jelenc
The Gigometer www.gigometer.com
The NYC Beer Guide www.nycbeer.org
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2020-01-15 10:40 -0500 |
| Message-ID | <qvnbpb$1db$1@jstuckle.eternal-september.org> |
| In reply to | #18189 |
On 1/14/2020 5:07 PM, Pierre Jelenc wrote: > In article <qvgmro$k1e$1@jstuckle.eternal-september.org>, > Jerry Stuckle <jstucklex@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! -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2020-01-15 20:20 +0100 |
| Message-ID | <h89701Fri9rU1@mid.individual.net> |
| In reply to | #18191 |
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. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2020-01-11 23:13 -0500 |
| Message-ID | <qve6cf$iu$1@jstuckle.eternal-september.org> |
| In reply to | #18183 |
On 1/11/2020 7:26 PM, Pierre Jelenc wrote: > In article <qvdkrp$eq7$1@jstuckle.eternal-september.org>, > Jerry Stuckle <jstucklex@attglobal.net> wrote: >> On 1/11/2020 5:23 PM, Pierre Jelenc wrote: >>> In article <qvcqip$6bl$1@jstuckle.eternal-september.org>, >>> Jerry Stuckle <jstucklex@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. > > Pierre > (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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2020-01-11 11:52 -0500 |
| Message-ID | <qvcuh4$upv$1@dont-email.me> |
| In reply to | #18173 |
^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 <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 "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2020-01-11 11:54 -0500 |
| Message-ID | <qvcukg$upv$2@dont-email.me> |
| In reply to | #18177 |
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 > <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 "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | ^Bart <gabriele1NOSPAM@hotmail.com> |
|---|---|
| Date | 2020-01-12 00:45 +0100 |
| Message-ID | <qvdmn0$8es$1@gioia.aioe.org> |
| In reply to | #18178 |
> 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
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2020-01-11 23:16 -0500 |
| Message-ID | <qve6hs$iu$2@jstuckle.eternal-september.org> |
| In reply to | #18178 |
On 1/11/2020 11:54 AM, Lew Pitcher wrote: > 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 > >> <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". >> >> > > On Apache you can do it even easier in your .htaccess file, but that's off topic for this group. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "J.O. Aho" <user@example.net> |
|---|---|
| Date | 2020-01-04 18:02 +0100 |
| Message-ID | <h7buptFnr4gU1@mid.individual.net> |
| In reply to | #18169 |
On 04/01/2020 16.41, ^Bart wrote: > 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 :\ 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
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | comp.lang.php
csiph-web