|
Oh, I was unaware crypt() did the bcrypt thing, thanks for that. Unrelated: Can PHP session variables be spoofed at all by a user? For example, let's say I authenticate a user and store some information about the user in the session variables such as: uid username hashedpassword Now, I wan't to display some records based on the id of the user (uid). Can I safely rely on the uid I wrote to the session variables or should I do a lookup of the user with the username and hashed password and get the uid that way? The latter is more secure (I think?) but requires one additional SQL query. The only problem I see with the former is that the user could potentially spoof their uid and see someone else's records. Is this possible to do? IT Guy fucked around with this message at 15:53 on Aug 2, 2012 |
#
?
Aug 2, 2012 15:47
|
|
|
|
| # ? May 19, 2024 19:49 |
|
|
IT Guy posted:Oh, I was unaware crypt() did the bcrypt thing, thanks for that. Sessions are generally stored server side, unless the option for cookie based sessions is on. This means the user only has the session, which links up with the data on your side. It's possible for a Man in the Middle attack so someone could spoof the session id, but you have larger problems then, and it's something doing a db lookup isn't going to help with. I would avoid storing the hashedpassword in the session, as if they have a session with a user id, you could safely assume they are authenticated. Username is also suspect, since then you have to keep the session up to date with any changes that are made. Plus the less data the server has to read off disk for the session the better. There are some good practices for sessions, like copying the session to a new id on every page load, this helps prevent MitM, but adds server load, and sometimes issues with AJAX/async requests.
|
|
#
?
Aug 2, 2012 15:56
|
|
|
MrEnigma posted:There are some good practices for sessions, like copying the session to a new id on every page load, this helps prevent MitM, but adds server load, and sometimes issues with AJAX/async requests. And I agree, you shouldn't need to store the password in the session. What's the point? When are you going to be looking at that again? Authenticate once and that's it, you shouldn't be authenticating on each load. Username I can see some benefit to, in terms of logging or display or what not, based on your system, but definitely not password.
|
|
#
?
Aug 2, 2012 16:04
|
|
|
Thanks for that, clears up some confusion. So just to be 100% clear, they could potentially spoof their session ID, but never the variables inside the session since it's stored on the server, correct? Also this cleared it up for me as well: http://stackoverflow.com/questions/6483092/php-session-hijacking As for storing the hashed password, what do you guys do if you revoke someones privileges? With your method, the user would stay logged in even if you deleted the user from your database, at least until the session expired. By storing the hashed password in a session variable, I can do a "SELECT COUNT(*) FROM users WHERE username = :username AND password = :password" to make sure they are still in the database.
|
|
#
?
Aug 2, 2012 16:17
|
|
|
IT Guy posted:Thanks for that, clears up some confusion. So just to be 100% clear, they could potentially spoof their session ID, but never the variables inside the session since it's stored on the server, correct? I've always ended up needing some other data for the user that was in the DB already, so it gets loaded every time, and if not in the db, it fails. I'd recommend at least checking, this will allow you to grab the username/email/etc that you need as well without clogging up sessions with it.
|
|
#
?
Aug 2, 2012 16:23
|
|
|
IT Guy posted:As for storing the hashed password, what do you guys do if you revoke someones privileges? With your method, the user would stay logged in even if you deleted the user from your database, at least until the session expired. By storing the hashed password in a session variable, I can do a "SELECT COUNT(*) FROM users WHERE username = :username AND password = :password" to make sure they are still in the database. Every page load should check to be sure the user is logged in. If you revoke privileges, you should have something check that the privileges were revoked and it will clear their session and force them to logout. This is one benefit of storing session data in the database, you can easily revoke a logged in user's privileges by deleting the session data from the db.
|
|
#
?
Aug 2, 2012 16:24
|
|
|
DarkLotus posted:Every page load should check to be sure the user is logged in. If you revoke privileges, you should have something check that the privileges were revoked and it will clear their session and force them to logout. This is one benefit of storing session data in the database, you can easily revoke a logged in user's privileges by deleting the session data from the db. This is exactly what I'm doing at the moment with the exception of storing the session in the database. IT Guy fucked around with this message at 23:42 on Aug 2, 2012 |
|
#
?
Aug 2, 2012 16:26
|
|
|
IT Guy posted:Thanks for that, clears up some confusion. So just to be 100% clear, they could potentially spoof their session ID, but never the variables inside the session since it's stored on the server, correct? Never the variables inside. Those are as safe as any other variable used in a PHP script, minus of course the $_REQUEST family. They cannot touch $_SESSION, beyond the session ID. As for "check if they're logged in", you can do this without their password. On every page request, re-authorize. "Do I have permission to view this page, or even to be logged in?" You can do this without their password being stored in the session. "To make sure they are still in the database" For one thing, you can do that with just their username or user ID; for another, don't delete users. Put simply: You need a password to authenticate, you do not need it to authorize. You authenticate only once, but authorize as needed.
|
|
#
?
Aug 2, 2012 16:42
|
|
|
I'm going from memory without checking any actual code so forgive me if this is wrong. Basically when you first authorize a user (logged in) you store a variable in $_SESSION[] saying that they are authorized. Let's say $_SESSION['authorized'] = true so now you add a method at the head of every protected page that checks that this session variable is set to true and any other checks you may wish to perform like seeing if they have the correct privileges. If they don't then use header() to redirect then to the login page with some message explaining why.
|
|
#
?
Aug 2, 2012 23:50
|
|
|
I like to let MySQL do the work when it can such as formatting data that is being inserted, for example, a timestamp I would query "INSERT INTO `table` SET `date` = UTC_TIMESTAMP". However, I was about to do the same with a change password form for users, for example: "INSERT INTO `users` SET `password` = SHA2('saltpassword', '256')" I then realized, this is probably bad because the password could be pulled out of our binary logs, correct? If so, I should make PHP hash the password, right?
|
|
#
?
Aug 3, 2012 15:06
|
|
|
Could run it and see if "SHA('saltpassword', '256')" gets put into the binary log, or if the result of the SHA() function does, in which case you're good. I know the result of NOW() is evaluated before being put into the binary log.
|
|
#
?
Aug 3, 2012 15:19
|
|
|
Good idea, I just gave it a go and it does not parse it. It doesn't log the result, it logs the query as written which in the binary log looks like this:code:Edit: found this in the MySQL documentation: quote:Caution IT Guy fucked around with this message at 17:00 on Aug 3, 2012 |
|
#
?
Aug 3, 2012 16:45
|
|
|
Hmm, when I call a getter for one of my properties, the output just says "Array" instead of what I expected (a date). When a user logs in, I call $instance->setDate(getdate()). Then I redirect them to a page that displays a bunch of information (echo $instance->getDate(); ), and it should have that Date property of the object, which should be the current date. Instead it just prints out "Array" text. As I'm typing this I realized I don't even want to set the date when they log in, it should be when they log out, but regardless.. Why would I be getting text? Sab669 fucked around with this message at 04:12 on Aug 9, 2012 |
|
#
?
Aug 9, 2012 03:32
|
|
|
Sab669 posted:Hmm, when I call a getter for one of my properties, the output just says "Array" instead of what I expected (a date). The date object that is being returned appears to be an array. When you echo an array you get the string 'Array'. print_r/var_dump it instead and you will see the date array.
|
|
#
?
Aug 9, 2012 03:53
|
|
, and it should have that Date property of the object, which should be the current date. Instead it just prints out "Array" text.
|
Ok, this might be weird but hopefully isn't a subject that's been gone over too much- what are the popular file name conventions for PHP? I spend a lot of time rooting through other people's content management systems and projects at work, and I see three types- file_name.php file-name.php and file.name.php I mostly see file_name out in the wild, but both seem to work fine. Is this a matter of preference, and just staying consistent?
|
|
#
?
Aug 11, 2012 03:03
|
|
|
It usually depends on the type of file and personal preference. Using a filename that is self documenting is always a good idea though. If it is a normal page you might do something like product.php, contact.php, index.php etc. If it's a class: myClass.class.php A file containing functions: myFunctions.func.php A file that is included in other files like a header or footer: header.inc.php
|
|
#
?
Aug 11, 2012 03:08
|
|
|
The correct directory layout can remove any value in the .foo.php thing.
|
|
#
?
Aug 11, 2012 05:54
|
|
|
biochemist posted:Ok, this might be weird but hopefully isn't a subject that's been gone over too much- what are the popular file name conventions for PHP? Nowadays it's usually full camel case like MyClassName.php. See PSR-0 for more details on some attempt at standardization: https://gist.github.com/1234504/
|
|
#
?
Aug 11, 2012 11:12
|
|
|
I apologise in advance if this isn't the place to ask, but I'd like to know if this is a decent starter book to learn PHP. It was linked in an ad on these forums. I'm going to be starting a programming course in a couple of months, so even though PHP isn't completely relevant I thought it might be a nice stepping stone to get my gears rolling again.
|
|
#
?
Aug 11, 2012 17:52
|
|
|
The bits of the preview of the book are correct-looking. Really, the gotchas in most of these is that they don't prepare you for the defensive programming mindset needed in order to avoid SQL Injection, CSRF and XSS.
|
|
#
?
Aug 11, 2012 21:39
|
|
|
Dodoman posted:I apologise in advance if this isn't the place to ask, but I'd like to know if this is a decent starter book to learn PHP. It was linked in an ad on these forums. I can never recommend this book enough to beginners. http://www.sitepoint.com/books/phpmysql5/ I've read the 3rd edition, 4th edition and now the 5th edition and every time the author steps it up with modern day best practices such as using PDO instead of mysql(i), keeping PHP separated from your HTML with simple templating, and well, just get it. You will not regret it. The author also explains where and how many security holes pop up. He explains using htmlspecialchars() to sanitize your user input for output, he goes into SQL injection. Just get it!
|
|
#
?
Aug 11, 2012 22:03
|
|
|
Awesome, it's half the price on Amazon. Thanks for the recommendation IT Guy.
|
|
#
?
Aug 12, 2012 09:23
|
|
|
Is there a good class out there to validate a range of form data including (or specifically) dates and times? I'm already validating it on the client side with JavaScript but I want to do it in PHP as well before submitting it to the database.
|
|
#
?
Aug 13, 2012 16:59
|
|
|
IT Guy posted:Is there a good class out there to validate a range of form data including (or specifically) dates and times? There are the filter functions: http://us2.php.net/manual/en/book.filter.php but they don't do date and times. Are the date and times coming in a predictably formatted field? For example, are they always Y-m-d H:i:s? If so, you can do this: php:<?
// Returns DateTime object if successful, false otherwise.
$date = DateTime::createFromFormat('Y-m-d H:i:s', $value);?>
|
|
#
?
Aug 13, 2012 17:06
|
|
|
Ah yes, that looks like it should work for me. Thanks.
|
|
#
?
Aug 13, 2012 17:14
|
|
|
So I'm working with a WSDL web service using PHP's SOAP client. The web service on the other end appears to be mainly made for using with C#/C++/etc as there are numerous calls that require data structures that are present in those languages but not in PHP. Has anyone here ever had to mimic the data structure "IEnumerable" and had it work when when passing it as a parameter for a PHP SOAP call? If so, could you provide some insight on how to do this? Googling turns up nothing.
|
|
#
?
Aug 14, 2012 20:53
|
|
|
IEnumerable is just an interface for what PHP would call an Iterator. Okay, well, it provides a method to get an IEnumerator, which is pretty much an Iterator. Regardless, it's just a fancy-rear end way to access what is basically an array. I highly recommend telling the idiots on the other end to give you a RESTful web service instead of dealing with SOAP. The buffoons that designed what you're working with aren't properly abstracting away their implementation details. You shouldn't be seeing anything about interfaces anywhere in the data sent over SOAP.
|
|
#
?
Aug 14, 2012 21:20
|
|
|
Yeah, it's been a mess in general. Before they had their web service accessible using only wsHttpBinding (with SOAP 1.2) which I fought with for a while before telling them that it simply doesn't work with PHP SOAP or NuSOAP. PHP soapclient doesn't support wsHttpBinding at all, and NuSOAP doesn't support SOAP 1.2. Couldn't find any other packages that would do the trick either. Eventually just pressured them into giving us a special 'update' that changed it to basicHTTPBinding. They were using wsHttpBinding for 'security' which is just a silly way of doing it when they could just have a login call that passes back a session key. I figured out what an IEnumerator is early on, but the problem of course is passing it properly to the web service to make it think it's an IEnumerator interface if it's even possible. I've tried all kinds of different ways of setting up arrays to see if that would work, but it didn't and I have a feeling it goes beyond that. Thanks for the info though, I doubt they'll actually make the web service RESTful anytime soon but hopefully I can put some pressure on them to do so.
|
|
#
?
Aug 14, 2012 21:52
|
|
|
e; god drat it, nevermind 
Sab669 fucked around with this message at 01:21 on Aug 16, 2012 |
|
#
?
Aug 16, 2012 01:17
|
|
|
I have learnt more about user authentication in the last two pages than I probably have over my entire time spent learning PHP. Thanks guys! On a separate note I have a problem that I'm not sure how to approach - I have a web site that uses "some data" to do "some stuff". I get the data via a web service that updates every 10 minutes, so theoretically if I access the web service every ten minutes I'll get the most recent data. I need to then take that data and insert some of it into a database. How do I do this? Is PHP even the appropriate tool for this? The nature of the web site means that I won't need to have up-to-date data if no one is on the web site (ie. I could access the web site and update the data on each page load) but I don't want to have it occur on every page load since it will create quite a bit of extra load time for every page. So yeah, crux of the issue - I need a script to run every 10 minutes and I need to know whether PHP is the right way to approach this or is there something else more suitable?
|
|
#
?
Aug 17, 2012 01:08
|
|
|
Gnack posted:I have learnt more about user authentication in the last two pages than I probably have over my entire time spent learning PHP. Thanks guys! PHP could be used for this. Any web scripting language could. Python, Perl or Ruby would also be usable. You schedule a cron job to run your script (whatever type of script) every 10 minutes.
|
|
#
?
Aug 17, 2012 01:29
|
|
|
Yeah, PHP can definietly do this job. You could have a cron job run a script that generates static output and call that file your index.html. For example: controller.php - your script that pulls the data from the web service. This is only run from generator.php generator.php - runs your controller.php script and generates the static output index.html page every 10 minutes via a cron job index.html - the page your visitors actually hit.
|
|
#
?
Aug 17, 2012 01:50
|
|
|
Hammerite posted:PHP could be used for this. Any web scripting language could. Python, Perl or Ruby would also be usable. You schedule a cron job to run your script (whatever type of script) every 10 minutes. IT Guy posted:Yeah, PHP can definietly do this job. Thanks guys, I had considered a cron job but I was under the impression my host doesn't allow cron jobs to run quite so frequently as 'every 10 minutes'. I had another look and it turns out they do! So I'll go with that approach - thanks!
|
|
#
?
Aug 17, 2012 02:05
|
|
|
Gnack posted:Thanks guys, I had considered a cron job but I was under the impression my host doesn't allow cron jobs to run quite so frequently as 'every 10 minutes'. I had another look and it turns out they do! So I'll go with that approach - thanks! Depending on the site traffic, how touchy your host is about cron jobs, and how long the site update function takes, you could always just implement a poor man's caching system, serialize some data to a file, and update the file on page load if it's >X minutes old.
|
|
#
?
Aug 17, 2012 02:41
|
|
|
Ursine Asylum posted:Depending on the site traffic, how touchy your host is about cron jobs, and how long the site update function takes, you could always just implement a poor man's caching system, serialize some data to a file, and update the file on page load if it's >X minutes old. This is good advice, thanks - I now have more than one option!
|
|
#
?
Aug 17, 2012 04:51
|
|
|
Have any of you guys heard of "PHP ActiveRecord"? I was talking to a co-worker about the clusterfuck shitfest that is my senior project group and he recommended trying to add it (I think we're too far along into the development, though) but it could be cool for future projects. Just curious if any of you guys have hands-on experience with it.
|
|
#
?
Aug 20, 2012 18:44
|
|
|
All ORMs suck. It's just a matter of where you want the suck to live. A major problem with ActiveRecord is that it violates SOLID and separation of concerns, and requires a great deal of additional work in order to perform automated testing.
|
|
#
?
Aug 20, 2012 21:01
|
|
|
McGlockenshire posted:All ORMs suck. It's just a matter of where you want the suck to live. Yup, for any marginally complex query, you're going to have to write SQL anyway. I'm using Doctrine2 for a lot of stuff and while I like the way Repositories work, I find myself writing a lot of SQL. However, if you do want to use an ORM, don't write one yourself. You're in a world of pain if you do.
|
|
#
?
Aug 20, 2012 21:35
|
|
|
McGlockenshire posted:All ORMs suck. It's just a matter of where you want the suck to live. As a PHP newbie, I want to make sure I'm parsing this properly: are you saying that "All ORMs suck" therefore you shouldn't use one? Or "All ORMs suck" but it's a necessary evil so pick the best of the crappy offerings? One of my biggest problems at the moment is getting the hang of the overall structure of a large PHP project and managing the database connection and queries etc is a big of a pain for me right now, so this topic is particularly interesting to me. putin is a cunt fucked around with this message at 00:08 on Aug 22, 2012 |
|
#
?
Aug 22, 2012 00:02
|
|
|
|
| # ? May 19, 2024 19:49 |
|
|
As a PHP newbie, may I ask why you're working on an large project?
|
|
#
?
Aug 22, 2012 01:34
|
|
