php-general Digest 31 May 2013 01:36:53 -0000 Issue 8253
Topics (messages 321279 through 321284):
Re: limit access to php page
321279 by: tamouse mailing lists
321280 by: Jim Giner
321282 by: Tedd Sperling
321283 by: Paul M Foster
Re: need some regex help to strip out // comments but not http:// urls
321281 by: David Harkness
Looking for a good working PDO and/or mysqli database class to get started with
OOP
321284 by: dealTek
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 May 30, 2013 8:10 AM, "Jim Giner" <jim.gi...@albanyhandball.com> wrote:
>
> 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 execute.
I want to throw in a caveat here, and that is the open_basedir directive,
wbicb limits where you can include files from.
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.
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
On 5/30/2013 10:22 AM, tamouse mailing lists wrote:
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 execute.
I want to throw in a caveat here, and that is the open_basedir directive,
wbicb limits where you can include files from.
Once again - an additional truth provided. In my case, upon checking I
see that setting was provided by my hoster and was set to null, so I was
never aware of a possible restriction.
--- End Message ---
--- Begin Message ---
On May 29, 2013, at 11:05 PM, Paul M Foster <pa...@quillandmouse.com> wrote:
>> 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:
While the above link may be example code, it is still sound for production.
Keep in mind that everything in security comes down to a true/false condition.
Do you let the person in or not!
Certainly there are attacks on session ids and one must deal with that. But
that's the level of security we have today.
I could go through all the things you need to consider in protecting your
session id (e.g., not accessing your bank accounts while having coffee at
StartBucks) but that would defeat the purpose of attending one of my classes on
the subject. :-)
If you are very concerned about security, then jump to a https protocol for
those transactions; change session ids frequently; monitor the user's local
environmental changes; time the session, and do a bunch of other stuff that
will make it more and more difficult for your user to use your service. But for
*most things* using a session id will keep things relatively safe.
Cheers,
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--- End Message ---
--- Begin Message ---
On Thu, May 30, 2013 at 12:06:02PM -0400, Tedd Sperling wrote:
> On May 29, 2013, at 11:05 PM, Paul M Foster <pa...@quillandmouse.com>
> wrote:
> >> 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:
>
> While the above link may be example code, it is still sound for
> production.
>
> Keep in mind that everything in security comes down to a true/false
> condition. Do you let the person in or not!
>
> Certainly there are attacks on session ids and one must deal with
> that. But that's the level of security we have today.
>
> I could go through all the things you need to consider in protecting
> your session id (e.g., not accessing your bank accounts while having
> coffee at StartBucks) but that would defeat the purpose of attending
> one of my classes on the subject. :-)
Yep, next time I'm up at the North Pole, I'll drop in and see you.
Meantime, the beach is heating up. Better go get some more ice for my
margueritas. [grin]
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--- End Message ---
--- Begin Message ---
On Wed, May 29, 2013 at 10:20 AM, Matijn Woudt <tijn...@gmail.com> wrote:
> It is possible to write a whole parser as a single regex, being it terribly
> long and complex.
>
While regular expressions are often used in the lexer--the part that scans
the input stream and breaks it up into meaningful tokens like
{ keyword: "function" }
{ operator: "+" }
and
{ identifier: "$foo" }
that form the building blocks of the language--they aren't combined into a
single expression. Instead, a lexer generator is used to build a state
machine that switches the active expressions to check based on the previous
tokens and context. Each expression recognizes a different type of token,
and many times these aren't even regular expressions.
The second stage--combining tokens based on the rules of the grammar--is
more complex and beyond the abilities of regular expressions. There are
plenty of books on the subject and tools [1] to build the pieces such as
Lex, Yacc, Flex, and Bison. Someone even asked this question on Stack
Overflow [2] a few years ago. And I'm sure if you look you can find someone
that did a masters thesis proving that regular expressions cannot handle a
context-free grammar. And finally I leave you with Jeff Atwood's article
about (not) parsing HTML with regex. [3]
Peace,
David
[1] http://dinosaur.compilertools.net/
[2]
http://stackoverflow.com/questions/3487089/are-regular-expressions-used-to-build-parsers
[3]
http://www.codinghorror.com/blog/2009/11/parsing-html-the-cthulhu-way.html
--- End Message ---
--- Begin Message ---
Hi all, Thanks for your help...
I'm looking for a very good, pre made, working PDO and/or mysqli database class
(in a wrapper) - to get started with, that has all the basic needs like UPDATE
- INSERT - DELETE - QUERY etc. That would be very helpful. I'm also trying to
learn OOP, and creating my own class to start out is over my head, so one that
is recommended here would be a good start.
There are many examples on the net - The problem is that commenters often have
issues with the code, and as a beginner in this area - these issues are
sometimes over my head and it would be best for me if someone could recommend a
good working standard model to start.
Q: DOES ANYONE HAVE ANY OPINIONS ON THE ONES BELOW?
- - - - - MySQLi
https://github.com/ajillion/PHP-MySQLi-Database-Class
http://www.phpclasses.org/package/2359-PHP-MySQL-database-wrapper-using-MySQLi-extension.html
http://snipplr.com/view/22992/
Jeffrey Way...
http://forrst.com/posts/Mysqli_Database_Class-hxb
http://www.dotred.be/blog/database-classes-for-mysql-mysqli-and-mssql/
- - - - - PDO
Jeffrey Way - some issues here in comments
http://net.tutsplus.com/tutorials/php/php-database-access-are-you-doing-it-correctly/
http://www.phpclasses.org/package/7533-PHP-Access-SQL-databases-using-PDO.html
http://www.doctrine-project.org/projects/dbal.html
http://pear.php.net/package/MDB2
--
Thanks,
Dave - DealTek
deal...@gmail.com
[db-3]
--- End Message ---
