php-general Digest 30 May 2013 13:09:09 -0000 Issue 8252
Topics (messages 321266 through 321278):
Re: limit access to php page
321266 by: Jim Giner
321267 by: Glob Design Info
321268 by: tamouse mailing lists
321269 by: Jim Giner
321270 by: tamouse mailing lists
321271 by: jomali
321272 by: Paul M Foster
321273 by: Camilo Sperberg
321278 by: Jim Giner
Re: need some regex help to strip out // comments but not http:// urls
321274 by: Sebastian Krebs
Include/Require limit?
321275 by: Julian Wanke
321276 by: Julian Wanke
321277 by: David Robley
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On 5/29/2013 7:11 PM, Tim Dunphy wrote:
Hello list,
I've created an authentication page (index.php) that logs into an LDAP
server, then points you to a second page that some folks are intended to
use to request apache redirects from the sysadmin group (redirect.php).
Everything works great so far, except if you pop the full URL of
redirect.php into your browser you can hit the page regardless of the login
process on index.php.
How can I limit redirect.php so that it can only be reached once you login
via the index page?
Thank you!
Tim
I would simply place my redirect.php script outside of the
web-accessible tree. The user can never type that uri into his browser
and have it work.
--- End Message ---
--- Begin Message ---
On 5/29/13 6:14 PM, Jim Giner wrote:
On 5/29/2013 7:11 PM, Tim Dunphy wrote:
Hello list,
I've created an authentication page (index.php) that logs into an LDAP
server, then points you to a second page that some folks are intended to
use to request apache redirects from the sysadmin group (redirect.php).
Everything works great so far, except if you pop the full URL of
redirect.php into your browser you can hit the page regardless of the
login
process on index.php.
How can I limit redirect.php so that it can only be reached once you
login
via the index page?
Thank you!
Tim
I would simply place my redirect.php script outside of the
web-accessible tree. The user can never type that uri into his browser
and have it work.
I always see this answer a lot but never any sample code of how to
include that file using require_once() or include_once().
It would be nice to know the exact syntax of inclusion of such files.
Say, for example if I put the login/redirect .php file 3-4 levels up
from my webroot.
-d
--- End Message ---
--- Begin Message ---
On Wed, May 29, 2013 at 8:14 PM, Jim Giner <jim.gi...@albanyhandball.com> wrote:
> On 5/29/2013 7:11 PM, Tim Dunphy wrote:
>>
>> Hello list,
>>
>> I've created an authentication page (index.php) that logs into an LDAP
>> server, then points you to a second page that some folks are intended to
>> use to request apache redirects from the sysadmin group (redirect.php).
>>
>> Everything works great so far, except if you pop the full URL of
>> redirect.php into your browser you can hit the page regardless of the
>> login
>> process on index.php.
>>
>> How can I limit redirect.php so that it can only be reached once you login
>> via the index page?
>>
>> Thank you!
>> Tim
>>
> I would simply place my redirect.php script outside of the web-accessible
> tree. The user can never type that uri into his browser and have it work.
Depends on whether the redirect is by header or not, if it is via the
Location header, then the browser has to be able to hit it.
There is, though, a form of application architecture where everything
is run through the index page, and it pulls things in via
include/require as directed.
--- End Message ---
--- Begin Message ---
On 5/29/2013 9:20 PM, Glob Design Info wrote:
On 5/29/13 6:14 PM, Jim Giner wrote:
On 5/29/2013 7:11 PM, Tim Dunphy wrote:
Hello list,
I've created an authentication page (index.php) that logs into an LDAP
server, then points you to a second page that some folks are intended to
use to request apache redirects from the sysadmin group (redirect.php).
Everything works great so far, except if you pop the full URL of
redirect.php into your browser you can hit the page regardless of the
login
process on index.php.
How can I limit redirect.php so that it can only be reached once you
login
via the index page?
Thank you!
Tim
I would simply place my redirect.php script outside of the
web-accessible tree. The user can never type that uri into his browser
and have it work.
I always see this answer a lot but never any sample code of how to
include that file using require_once() or include_once().
It would be nice to know the exact syntax of inclusion of such files.
Say, for example if I put the login/redirect .php file 3-4 levels up
from my webroot.
-d
simply a require statement pointing to the script. PHP can load
anything, http can only see the web tree.
I personally have a std. set of code in my scripts that always creates a
var that points to my document root (web root) and another that points
to my php folder which is outside of the web root.
As for the location - it need be only one level above or at a level
parallel but outside of the web root. My hoster actually sets up their
accounts with a 'php' folder at the same level as the "public_html" (web
root) folder.
--- End Message ---
--- Begin Message ---
On Wed, May 29, 2013 at 8:20 PM, Glob Design Info <i...@globdesign.com> wrote:
> On 5/29/13 6:14 PM, Jim Giner wrote:
>>
>> On 5/29/2013 7:11 PM, Tim Dunphy wrote:
>>>
>>> Hello list,
>>>
>>> I've created an authentication page (index.php) that logs into an LDAP
>>> server, then points you to a second page that some folks are intended to
>>> use to request apache redirects from the sysadmin group (redirect.php).
>>>
>>> Everything works great so far, except if you pop the full URL of
>>> redirect.php into your browser you can hit the page regardless of the
>>> login
>>> process on index.php.
>>>
>>> How can I limit redirect.php so that it can only be reached once you
>>> login
>>> via the index page?
>>>
>>> Thank you!
>>> Tim
>>>
>> I would simply place my redirect.php script outside of the
>> web-accessible tree. The user can never type that uri into his browser
>> and have it work.
>
>
> I always see this answer a lot but never any sample code of how to include
> that file using require_once() or include_once().
>
> It would be nice to know the exact syntax of inclusion of such files.
>
> Say, for example if I put the login/redirect .php file 3-4 levels up from my
> webroot.
Okay, first off, your application *has* to have some entry point that
*is* accessible to a browser; otherwise nothing will find it.
THe include/require(_once) directives take as an argument a file path
including file name, there is no requirement they be in the same
directory or lower as the calling file.
So let's take this as a example:
Application/webroot/index.php
Application/includes/redirect.php
Application/includes/login.php
index.php:
<?php
session_start();
if (valid_user($_SESSION['current_user'])) {
include_once("../includes/redirect.php");
} else {
include_once("../includes/login.php");
}
?>
This the so-called single script entry style for designing your app. A
consequence of this is that it makes bookmarking a bit different. One
example of this is the PmWiki application. Everything runs through the
main script (in this case it's called pmwiki.php instead of index.php,
but that's immaterial here). Pages in the wiki are given on the path,
such as: http://www.pmwiki.org/wiki/PmWiki/PmWiki, which makes it
bookmarkable and work in the browser history. Others may not; it all
depends on what you want.
--- End Message ---
--- Begin Message ---
On Wed, May 29, 2013 at 9:20 PM, Glob Design Info <i...@globdesign.com>wrote:
> On 5/29/13 6:14 PM, Jim Giner wrote:
>
>> On 5/29/2013 7:11 PM, Tim Dunphy wrote:
>>
>>> Hello list,
>>>
>>> I've created an authentication page (index.php) that logs into an LDAP
>>> server, then points you to a second page that some folks are intended to
>>> use to request apache redirects from the sysadmin group (redirect.php).
>>>
>>> Everything works great so far, except if you pop the full URL of
>>> redirect.php into your browser you can hit the page regardless of the
>>> login
>>> process on index.php.
>>>
>>> How can I limit redirect.php so that it can only be reached once you
>>> login
>>> via the index page?
>>>
>>> Thank you!
>>> Tim
>>>
>>> I would simply place my redirect.php script outside of the
>> web-accessible tree. The user can never type that uri into his browser
>> and have it work.
>>
>
> I always see this answer a lot but never any sample code of how to include
> that file using require_once() or include_once().
>
> It would be nice to know the exact syntax of inclusion of such files.
>
> Say, for example if I put the login/redirect .php file 3-4 levels up from
> my webroot.
>
> require_once('../../../redirect.php');
--- End Message ---
--- Begin Message ---
On Wed, May 29, 2013 at 08:51:47PM -0400, Tedd Sperling wrote:
> On May 29, 2013, at 7:11 PM, Tim Dunphy <bluethu...@gmail.com> wrote:
>
> > Hello list,
> >
> > I've created an authentication page (index.php) that logs into an LDAP
> > server, then points you to a second page that some folks are intended to
> > use to request apache redirects from the sysadmin group (redirect.php).
> >
> > Everything works great so far, except if you pop the full URL of
> > redirect.php into your browser you can hit the page regardless of the login
> > process on index.php.
> >
> > How can I limit redirect.php so that it can only be reached once you login
> > via the index page?
> >
> > Thank you!
> > Tim
> >
> > --
> > GPG me!!
>
> Try this:
>
> http://sperling.com/php/authorization/log-on.php
I realize this is example code.
My question is, in a real application where that $_SESSION['auth'] token
would be used subsequently to gain entry to other pages, what would you
use instead of the simple TRUE/FALSE value? It seems that someone (with
far more knowledge of hacking than I have) could rather easily hack the
session value to change its value. But then again, I pretty much suck
when it comes to working out how you'd "hack" (crack) things.
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--- End Message ---
--- Begin Message ---
On 30 mei 2013, at 05:05, Paul M Foster <pa...@quillandmouse.com> wrote:
> On Wed, May 29, 2013 at 08:51:47PM -0400, Tedd Sperling wrote:
>
>> On May 29, 2013, at 7:11 PM, Tim Dunphy <bluethu...@gmail.com> wrote:
>>
>>> Hello list,
>>>
>>> I've created an authentication page (index.php) that logs into an LDAP
>>> server, then points you to a second page that some folks are intended to
>>> use to request apache redirects from the sysadmin group (redirect.php).
>>>
>>> Everything works great so far, except if you pop the full URL of
>>> redirect.php into your browser you can hit the page regardless of the login
>>> process on index.php.
>>>
>>> How can I limit redirect.php so that it can only be reached once you login
>>> via the index page?
>>>
>>> Thank you!
>>> Tim
>>>
>>> --
>>> GPG me!!
>>
>> Try this:
>>
>> http://sperling.com/php/authorization/log-on.php
>
> I realize this is example code.
>
> My question is, in a real application where that $_SESSION['auth'] token
> would be used subsequently to gain entry to other pages, what would you
> use instead of the simple TRUE/FALSE value? It seems that someone (with
> far more knowledge of hacking than I have) could rather easily hack the
> session value to change its value. But then again, I pretty much suck
> when it comes to working out how you'd "hack" (crack) things.
>
> Paul
>
> --
> Paul M. Foster
> http://noferblatz.com
> http://quillandmouse.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
$_SESSION value are quite secure, as they are set on the server, only you can
control what's inside them. What can be hacked is the authentification process
or some script that sets session values. There is also a way of hijacking a
session, but again: its values aren't changed by some PHP script, the session
is being hijacked. Don't pass urls with the session id within them and you'll
be save.
Greetings.
Sent from my iPhone 6 Beta [Confidential use only]
--- End Message ---
--- Begin Message ---
On 5/29/2013 9:38 PM, tamouse mailing lists wrote:
Okay, first off, your application *has* to have some entry point that
*is* accessible to a browser; otherwise nothing will find it.
Once again - I was wrong in my suggestion as Ashley has pointed out so
correctly. Had to test it out this morning only to discover that I had
never done quite that kind of Header redirect before.
So - the include method still works, as would the single script
'controller' method. Within a php script any file is accessible (within
your domain at least) and may therefore be included and executed. On
the other hand, if you must have the target script in your
web-accessible tree, simply establish some kind of security handler and
add logic to your page(s) to check permissions before displaying
anything. This handler could be based upon session vars, cookies, db
entries (my pref). Once established it can be a universal addition to
any and all of your appls.
My personal method is to create a db table containing an appl name, page
name, and a non-unique security level (I use an integer). Then have an
admin screen for creating userids for an appl with multiple recs each
containing a security level for that user for that appl. Then have a
signon method that validates credentials and builds a session array
containing all the user's security levels. In every page that I want
secured, I call a function with that script's internal pagename and appl
name and confirm that the page's sec level is contained in the user's
session array. I also have a master level (99) that if present gives
global access for myself as administrator. There's a bit more to it,
but that's my security method.
--- End Message ---
--- Begin Message ---
2013/5/29 Matijn Woudt <tijn...@gmail.com>
>
>
> On Wed, May 29, 2013 at 10:51 PM, Sebastian Krebs <krebs....@gmail.com>wrote:
>
>>
>>
>>
>> 2013/5/29 Matijn Woudt <tijn...@gmail.com>
>>
>>> On Wed, May 29, 2013 at 6:08 PM, Sean Greenslade <zootboys...@gmail.com
>>> >wrote:
>>>
>>> > On Wed, May 29, 2013 at 9:57 AM, Jonesy <gm...@jonz.net> wrote:
>>> > > On Tue, 28 May 2013 14:17:06 -0700, Daevid Vincent wrote:
>>> > >> I'm adding some minification to our cache.class.php and am running
>>> into
>>> > an
>>> > >> edge case that is causing me grief.
>>> > >>
>>> > >> I want to remove all comments of the // variety, HOWEVER I don't
>>> want to
>>> > >> remove URLs...
>>> > >
>>> > > KISS.
>>> > >
>>> > > To make it simple, straight-forward, and understandable next year
>>> when I
>>> > > have to re-read what I've written:
>>> > >
>>> > > I'd change all "://" to "QqQ" -- or any unlikely text string.
>>> > >
>>> > > Then I'd do whatever needs to be done to the "//" occurances.
>>> > >
>>> > > Finally, I'd change all "QqQ" back to "://".
>>> > >
>>> > > Jonesy
>>> >
>>> > Wow. This is just a spectacularly bad suggestion.
>>> >
>>> > First off, this task is probably a bit beyond the capabilities of a
>>> > regex. Yes, you may be able to come up with something that works 99%
>>> > of the time, but this is really a job for a parser of some sort. I'm
>>> > sorry I don't have any suggestions on exactly where to go with that,
>>> > however I'm sure Google can be of assistance. The main problem is that
>>> > regex doesn't understand context. It just blindly finds patterns. A
>>> > parser understands context, and can figure out which //'s are comments
>>> > and which are something else. As a bonus, it can probably understand
>>> > other forms of comments like /* */, which regex would completely die
>>> > on.
>>> >
>>> >
>>> It is possible to write a whole parser as a single regex, being it
>>> terribly
>>> long and complex.
>>>
>>
>> No, it isn't.
>>
>
>
> It's better if you throw some smart words on the screen if you want to
> convince someone. Just thinking about it, it makes sense as a true regular
> expression can only describe a regular language, and I think all the
> programming languages are not regular languages.
> But, We have PHP PCRE with extensions like Recursive patterns[1] and Back
> references[2], which can describe much more than just a regular language.
> And I do believe it would be able to handle it.
> Too bad it probably takes months to complete a regular expression like
> this.
>
Then you start as soon as possible, so that you not realitze, that this is
wrong, when it is too late. I am not going to start explaining this again,
because it becomes a waste of time. You call it "smart words on the
screen", I call it "advice".
> - Matijn
>
> [1] http://php.net/manual/en/regexp.reference.recursive.php
> [2] http://php.net/manual/en/regexp.reference.back-references.php
>
--
github.com/KingCrunch
--- End Message ---
--- Begin Message ---
Hi,
I use the pretty large Library PHP Image Workshop
(http://phpimageworkshop.com/) at my project. It is about 75,5 KB.
Everything works fine but if I try to include a 15 KB file with country
codes, it fails.
With the other files I easily get over 100 KB inclusion size, so my
question;
Is there a size limitation for include?
Best regards
--- End Message ---
--- Begin Message ---
Hi,
it outputs a corrupt image (I think the function imagepng)
Am 30.05.2013, 11:17 Uhr, schrieb Alex Pojarsky <divine.ra...@gmail.com>:
Hey.
Afaik - only in case if your PHP process instance exeeds allowed memory limit.
Other then this - explain how does it fail exactly. Any error messages? Errorous behavior?
--- End Message ---
--- Begin Message ---
"Julian Wanke" wrote:
> Hi,
>
> I use the pretty large Library PHP Image Workshop
> (http://phpimageworkshop.com/) at my project. It is about 75,5 KB.
> Everything works fine but if I try to include a 15 KB file with country
> codes, it fails.
> With the other files I easily get over 100 KB inclusion size, so my
> question;
> Is there a size limitation for include?
>
> Best regards
Do you get an error message? Try removing the header() in the image output
and see what happens.
--
Cheers
David Robley
PARANOID:Paying MORE for Surge-Protectors than Computers
--- End Message ---
