gizmola

Yes, there's a nice jsfiddle here that demonstrates how to do this with jquery. The differences in approach would be: -You would use a size constrained Div instead of a text area. -"Reading completely" is considered to have happened when the user scrolls the scrollbar to the bottom of the T&C. Using this technique you can combine your activation of the checkbox with the scrolling to the bottom of the T&C.

A couple of clarifications -- All we are talking about is the method of authentication you are using to secure a section of your site. MySQL and php sessions have nothing to do with Authentication. We could compare and contrast mysql vs an htpasswd file and in many ways, using a mysql table will be superior, from the ability to have a simple custom status, to administration of the users, to the fact that your users won't even be able to update their own passwords. I realize it's not an apples/oranges comparison, and as I also mentioned it's possible to use HTTP auth AND utilize a mysql based user table. The main thing the HTTP Auth buys you is: -Built into the browser -No need to create your own auth form -In fact you can avoid any code whatsoever We can all agree that is the case, and for a quick and dirty security system, most of us have used it at one time or another. Actually it just takes one person. As for what is reasonably expected to happen or not, that is anyone's guess, but the simple fact of the matter is that it only takes one "trusted" person to use your site on wifi with someone sniffing, and they will be in. I don't think this is likely, however, I also don't think it's likely that someone is going to target your site for XSS exploitation either. They are equally unlikely scenarios, so what I'm really focused on, is the way you seem to be trying to make an argument in this thread that HTTP Auth is superior to a traditional PHP form based authentication script, that most likely uses php sessions. At the risk of repeating myself, what is also a significant weakness of HTTP Auth is that as long as the browser stays open the authentication is current. So if someone authenticates to your trusted area, anyone else who happens to use that browser will also be authenticated. You have no visibility into the authentication process since it entirely occurs between the browser and server, and you can't timeout or take any countermeasures against intrusion. I also was trying to make the point, that XSS has to have an exploit vector. If you are not allowing user content from people on your site, or if you are, however you have taken the necessary countermeasures, you don't need to worry about XSS. Your entire premise seems to be that XSS is highly likely, and thus XSS is your biggest worry, and your argument proceeds from there. In conclusion, I have nothing against HTTP Auth, and we've explored it a great deal in this thread, which may be useful to future developers. In your scenario, it seems like a reasonable time saving measure, although having used it myself, it has a high administration cost, in your having to setup users and communicate their passwords to them. Here's some skeleton code that could be used to authenticate a site, using HTTP Auth in PHP script form, which I alluded to previously. if (isset($_SERVER['PHP_AUTH_USER']) AND isset($_SERVER['PHP_AUTH_PW'])) { $valid = 0; $user = mysql_real_escape_string($_SERVER['PHP_AUTH_USER']); $password = sha1($_SERVER['PHP_AUTH_PW']); // Query database here for user/pw combination // $valid = result of SELECT count(*) .. FROM TABLE WHERE user = $user AND pwd = $password ... if ($valid !== 1) { header('WWW-Authenticate: Basic realm="Your Site Login"'); header('HTTP/1.0 401 Unauthorized'); unset($_SERVER['PHP_AUTH_USER']); unset($_SERVER['PHP_AUTH_PW']); exit; } } else { header('WWW-Authenticate: Basic realm="Your Site Login"'); header('HTTP/1.0 401 Unauthorized'); unset($_SERVER['PHP_AUTH_USER']); unset($_SERVER['PHP_AUTH_PW']); exit; }

It's really not better. First off, anyone who accesses your site in a cafe over wifi will be an easy target. This is equally a problem without HTTP Auth, but at least most competent session code will include some countermeasures against privilege escalation. One your HTTP Auth is compromised it's game over. HTTP Auth is basically wide open to brute force attacks. Secondly, if you have a small group of users, are you saying you don't trust them? How exactly will these XSS attacks occur? The small group of people you are talking about are actually not trustworthy? You seem to want to convince yourself that HTTP Auth security is in some way advantageous. It's an option that I've used myself a few times, and you can implement it programatically in PHP, which allows you to use a database table for example, rather than an htpasswd file. However, there should be no doubt that it is a quick and dirty somewhat antiquated system that exposes credentials repeatedly. Oh and did I mention that the only way you can clear the authentication is to close the browser?

icydash, HTTP Auth is a very poor level of authentication unless you're utilizing HTTPS. For most people it's used on intranets or quick and dirty security with a limited number of users.

Ditto on Carbon, I should have mentioned it. A lot of really nice stuff in there.

In terms of PHP, the DateTime class has timezone arithmetic built into it. Your approach is the same, only I would store the timezone string for each user, and use that to convert variables using the timezone class to do so.

Very good question. For security reasons there isn't an equivalent "getAllRequestHeaders". The security credentials are sent in the request to the server, and are not present in the response. Request (GET, POST, etc) Client -----> Server Response Client Needless to say, in an XMLHttpRequest, the entire point of the exercise is to get the response data back from the server, so they make the full range of headers available. The more typical concern with Realms is that someone might sniff your traffic and have access to the credentials directly. Your exploit code is typical of an xss cookie exploit, where what gets sent to the server via ajax is the value of document.cookie

DOM = Document Object Model. When you write javascript code, typically it is so that you can manipulate the DOM. Since javascript code runs on the client computer, it is exceedingly dangerous when your site allows people to store javascript code in your database. If an attacker manages to embed their javascript code in a page, users who access that page, inadvertantly will run the attackers code, which looks to them like it came from your site. None of the above. What you are talking about is HTTP Authentication. When you secure a directory using this form of authentication, the server prompts the client for a name and password combination to a particular "Realm". The .htpasswd file is simply a configuration detail. There are a variety of different options available, depending on your server, for how the usernames and passwords will be evaluated, and how the passwords are stored, so that they can be checked. Regardless of the format of the passwords, all forms of this authentication share the same mechanics. The browser sends the credentials in an HTTP Header field name "authorization:". Once you've authenticated with a realm, the browser continues to send this field (which is some form of the username and password at minimum) with every request. The mechanism is very similar to how a session cookie works.

Ha, that's pretty funny. Glad they have a sense of humor about it.

Ok, that is equivalent to what I was thinking, so I retract my prior statement. You could still do this in Redis, but if you want to stay with storing everything in mysql, then you are probably alright with your design. I'm not a huge fan of stored procedures on mysql -- they were more of an afterthought and performance wise, aren't the major boon that they are in other relational databases. In general mysql is optimized towards selects and inserts. Updates and deletes are not as good. I would definately suggest you use the innodb engine for this application if for no other reason that at least you will have row level locking.

There's nothing wrong with what ChristianF provided, and some good information there. As with most languages, there are numerous ways to skin the same cat. However, what jesirose was suggesting in regards to integers specifically, is that you can typecast the parameter that must be an integer. It is fairly well known that typecasting is the technique that performs the best, since it's a language construct and not a function that has to be called. I don't want to oversell it because in one script the difference between something that takes milliseconds is negligible, but you might as well learn about it. From looking at your sql statement, it looks as if you actually have 2 columns that are probably integers in the database -- id and avguse. $avguse = (int)$_POST[avguse]; $id = (int)$_POST[id]; If you experiment with this, you'll find that no matter what you put into the url parameters, the variables will be safely converted to integers. Of course when you put in strings, in most cases they will be converted to 0, so you want to make sure your query works acceptably even when zeros are passed.

I have to agree with the others, and from a relational design point of view, the shuffle state of the deck is not a direct attribute of the deck, so that should not be a column in the database. To keep it in the database, you could have a "shuffledDeck" table that relates to the Deck table. If you have any concern about scalability, then you would probably want to investigate what all the cool kids are doing, which is something like Redis to maintain state. Redis can be used to cache like memcache, but it also has a lot of extensions to it, and has a persistence mode that will save data to disk if you absolutely can't abide the infintessimal chance that your whole server shuts down and you might lose the state of the current games. These scenarios are over thought a lot of times, because people never test them or come up with any code that would handle the recovery of a situation like that anyways. Redis has some neat stuff in it like ZSCORE where you could use to represent your shuffled deck. Items are placed in the cache key in sorted order and can be retrieved using ZRANGEBYSCORE in sorted order.

CI is very simple, and easy for people to get up to speed with. It is also a framework that was developed for php4. PHP5 was released in July of 2004. The most successful PHP4 frameworks have been freshened and updated obviously, but that doesn't change the fact that they had to play by an entirely different set of rules 8 years ago. My considered opinion is as stated - those frameworks were great in their day, but developers who want to use a state of the (PHP) art framework will be looking at the ones I mentioned, or possibly some of the newer frameworks. Part of the success of any framework is the ecosystem around it. Symfony2 for example, already has a myriad of bundles that add all sorts of capabilities to it. Assuming there is an amenable architecture, the more interest there is in a framework, the more likely that there will be substantial plugins/modules/addons available for it. This is really the best answer I can give, because the premise of your question requires so many variables that several books could be written on the subject. One significant question is one of philosophy. What do you expect from a framework, and why are you using one? If it's to cobble together small websites that don't require a lot of sophistication, then your consideration of the relative capabilities of the framework is not that important. However, when there is a major change to the php language that profoundly changes how the practice of development works, I think you're better off tracking that and looking at why the changes were introduced and what problems they were meant to solve. Someone who truly knows the language can use any framework to solve problems, but ideally the framework is providing you a substantial base to work from.

You miss the point entirely. Someone new to frameworks is better off learning a framework that utilizes state of the art features of the language and best practices. Someone who is experienced with the language and already knows those features, is free to move from framework to framework and doesn't need to be concerned about working with something old, because they can just as easily use one of the more modern frameworks if need be. With that said, I expect that interest in CI will continue to dwindle now that PSR-0 is out, and the php framework world is moving towards Composer, and frameworks that can integrate the most functional and up to date libraries available.

Safest bet is the application of good old prescription (*100, round, divide by 100). originalvalue roundedvalue = Math.round(originalvalue*100)/100; You could also try roundedvalue = originalvalue.toFixed(2);

A framework is just a library. The old saying of "why reinvent the wheel?" applies. With that said, the better frameworks also bring a paradigm to the table. They typically give your application structure and provide components that typically make your application faster to develop in the short term, and easier to maintain in the long run. The general consensus is that the Model - View - Controller (MVC) design pattern is highly suited to the chore of developing a substantial website. If you're developing a new website my personal opinion is that you should code against one of the newer frameworks. The two most active projects are Symfony2 and Zend Framework2. I'd suggest that rather than trying to find a book, you are far better off, checking out the sites for each framework, looking at their documentation, downloading and installing them, and creating a simple application. There are many tutorials out there that can help you get your feet wet with each. People new to frameworks and MVC often find that older frameworks like Codeigniter or CakePHP are easier to get started with, but from my point of view, that's like investing in learning java development by reading a book that teaches you how to code using Visual J++. In other words, you'd be investing in something that has no future and is teaching you obsolete techniques.

Where exactly does Google stop you from right clicking?

I think you're taking offense a bit too easily. His post was simply trying to provide some constructive criticism. Easy enough to ignore if you feel it's inaccurate, but in reading some of the description of the product, I think you do need some help with your marketing material. Anyways, good luck with your company.

After prodding and poking, I got onto IRC with Phillip and forced him to figure out the problem. One little missing template and voila.. tutorials are back.

Fixed at last.

Stefan, In general we have some guidelines that have to be interpreted by the mods, and we give people a lot of discretion in making the decision of what goes and what stays. We take pride in the accomplishments of people like yourself and in general, the way we handle things like this, is that we are fairly liberal in allowing people to place links to sites in their signatures, so long as the people doing so are contributing members of the community. Every day, we have people who join and post a couple of bogus messages for no other reason than to try and siphon link juice or spam the forum with advertisements. The forum we have set aside for critiques is really for people who are actively developing their site, and want alpha/beta phase advice on them. It's not for people who have launched a site, either to advertise or to promote. So in short, while we celebrate your success, and are proud of your accomplishments as a developer, any promotion is against our ToS and guidelines. It tends to be that the best way to promote your site here, is to continue to participate and share your expertise back with the community. Some percentage of people will visit your site via the links in your sig.

Did you try out the code I provided as a sample? Unfortunately the format was a bit screwed up on some of the code tags but I fixed that. My sample was written to reflect your code and solve your problem. Of course if you don't know what a php array is, I guess anything in this regard is going to be confusing. Using the technique I demonstrated, you will get one array (again as long as at least one checkbox is checked) and this array will have values for any of the checkboxes. You can then assign this variable as is to a session variable, or use it to update a database.

First off your form, doesn't have a submit button, so I"m unclear how you are posting it. With that said, if you have a form that has a checkbox and you submit it with no checkbox checked, there will be nothing in the $_POST. So you need to know what the entire universe of checkboxes is, which you of course do know because you are providing the markup. What I'd suggest is that you name your groups of checkboxes with the same name, and use the array syntax. ... .... When you use this technique, your $_POST will include an array named services, so long as at least one checkbox is checked. This array will contain the VALUES for any of the checkboxes you provided. You can then set that to be a single session variable and re-read the values from that variable depending on what you want to do. See this sample program for clarity: #testform.php </pre> <form name="test" method="post"> T01 T02 </form> <br><br>var_dump($_POST);<br>?&g Check both boxes and submit and the output is:

Yes, although Pikachu2k is glossing some details. This is what I throught you meant, and why I stated it was non-trivial. If you are storing this favorite number in a user table, then Pikachu's suggestion is not a good idea in most cases, especially if you are relating other tables to user. The relations are done by the user.id column, and you would not want this to change for a user. What Pikachu2k is assuming is that the "favorite number" column would be in a seperate related table. This table might be named "userfavs" or something like that. If that table was related to User in a one to many fashion, then you could also include a timestamp column in it. When you joined the tables together you would only return the row that has the largest timestamp. While this is a sound relational design, which I've employed myself on many occassions, it makes everything a lot more complicated, as now you have joins, etc. Another solution to this that many people implement is to use a second user table. This table might be named userArchive. userArchive typically has the same structure as user, but would include a "changedAt" timestamp column. When a row in the user table is changed, as in the case of the person updating their favorite number, you will programmatically or by trigger, insert the "Old" row into the userArchive table. This also works really well, but adds significant extra overhead to any table updates, and of course increases the size of the database substantially. However, many programs that need very granular auditting implement some variation of this system. Last but not least, you can always have your application write out a change log, which summarizes the changes that were made. It reallly all depends on why you need this feature, and how you plan to use it. If it's just an audit trail, a text file can work really well, and doesn't require additional tables, although it does require code to work properly. Triggers are the most reliable and independent implementation, however mysql stored procs and triggers are not very efficient. Building the archiving right into the structure of the tables also can work well, but will cause your main tables to grow in size, which introduces overhead, as well as making basic queries more complicated. There is no single right answer to this --- it all depends on the specific use cases you have.

There is nothing automatic about slashes in php other than the magic_quotes_gpc which has been deprecated for a long time. Furthermore, the mysql api is deprecated for mysqli and when using that api you should use named parameters which means you don't need to escape characters. Last but not least, even if you are not using mysqli (or pdo which is an alternative with similar advantages) you should be using mysql_real_escape_string rather than addslashes.