ManiacDan

...and what's the problem here?

There's a number of things wrong here. First, your thread title is absolutely useless. Use the title to actually describe the problem. Now, to your actual code. Look at the error message: mysql_select_db is failing, with the error that the supplied argument is not valid. What argument are you supplying to that function? Let's look: mysql_select_db($database_cicpriva_reg, $cicpriva_reg); So your code believes $cicpriva_reg is the database object. Why isn't that correct? Go look at where you make the database object: $dibby = mysql_pconnect($hostname_cicpriva_reg, $username_cicpriva_reg, $password_cicpriva_reg) or trigger_error(mysql_error(),E_USER_ERROR); As PFMaBiSmAd and mikosiko have both already explained, $dibby is not $cicpriva_reg Your database column names are unusual, but not technically incorrect if this is MySQL. You should try to avoid using special characters like / and \ in your column names, and stick to only letters, numbers, and the underscore character. That ensures interoperability.

Are you sure the tags are part of the file? Some music players store the tags outside of the file itself. Also, bumping threads is against the rules. You posted in the middle of the night US time.

PHP is a young language. Tutorials which are 5-6 years old are no longer valid, yet they still exist because that's really not that long ago. Using the session in the URL is wrong. Stick to books and tutorials written since the release of PHP 5.3. It's part of the request header, visible from $_COOKIE since it's a cookie. I don't believe it's in $_SERVER, that's another part of the header. It is not in GET or POST Welcome to web programming. 5 distinct languages, 10 technologies, and an entire theory of programming. Good luck. The problem you're having is twofold: 1) Most of what you're saying isn't part of "web programming" at all, it's part of "internet communications." The REMOTE_ADDR that you see in PHP's $_SERVER array is not special to PHP, apache, or the web. It's part of TCP itself. That same header is where cookies live, but cookies are unique to web development. 2) It's difficult to answer such a deep question without getting too technical. To give you half the answer is disingenuous, because then you end up thinking you have the whole answer when you don't have much at all. Everything is built in layers. Honestly, if you're that interested, start at the OSI Model. That's the actual "stack" that governs internet communication as a whole. Understanding that allows you to realize that Apache and PHP sit at the uppermost layer (layer 7, application). Once you know how internet communication works and how actual messages are constructed and what constitutes a "connection" (which is really just random packets), then you understand why client-server programming is stateless (and it's silly to try to maintain form post state, like we discussed before). A good top-level summary of PHP is: 0) The user clicks a link, which instructs his computer to set a GET (or POST) request to your server. The browser formulates the base packet headers. 1) Other things (apache, the OS, the network card itself) manage communications speeds, getting data to and from the client, and handling communication metadata (IP address, user-agent, cookies, forwarding headers, proxying, cache control, and dozens of other pieces of information that come through with every request). POST is part of the header as well. 2) PHP receives a request and $_SERVER, $_COOKIE, $_GET, and $_POST already exist. PHP scripts are, for the most part, safe to assume everything in those arrays is correct (correct, not valid). 3) PHP processes its data, performs queries, reads files, etc. While the session is unique to each user, and $_POST and $_GET (as well as all other script variables) are unique to each request, the files and database are unique only to each server. It's confusing, and must be thought through extensively before you get good at it. 4) PHP spits out (usually) an HTML formatted string, which may or may not contain references to other documents, CSS, JavaScript, etc. 5) That message is transmitted to the user, along with all the header information relevant to that request. The headers that the server sends include the content type, cache control, location headers, status codes, redirects, cookies, and more. This is the packet header, not the HTML <head> tag. Do not get them confused. 6) The user receives the packets from the server and constructs them into a displayable message, rendering the HTML and executing the javascript on the user's end. Javascript is executed on the user's computer and has no access to anything but (usually) the current page contents. If any additional documents were linked to (like <img> or <script> tags), they are fetched as well. 7) A request has been complete, from click to display. PHP clears out memory entirely when your script dies. Each PHP "program" runs for less than a second apiece (if you do it right). PHP also clears out physical session files periodically based on the php.ini settings. Additionally, your operating system clears out /tmp periodically based on file age, since that's what /tmp is for. You are not responsible for garbage collection on any level. The only exception to this is if you store garbage in your database on purpose (like if you store sessions in the database) or if your scripts are using so much memory that they need to be cleaned mid-execution.

Not a valid reality, unless there's a very serious security hole in the browser itself. If the browser itself is compromised, your site is just as vulnerable as everyone else's. Both methods are valid. Note that absolute paths are probably always preferred anyway, so in case you move a page to a different "depth" in your site, all the links still work. Kicken addressed this, but I wanted to back him up: Negligible. All true. You can use php.ini to make the session cookie last longer than the current browsing session, but that's rarely done. The serialization format is not the same as the one for serialize(). It's very similar, but not the same. Nobody knows why, it's annoying and stupid. The reason why I mentioned tabbing is because if you use $_SESSION['formCheckHash'] to store this form validation hash, what happens if you draw two forms back to back in the same session? There will be two hashes, and only one value. One form will never be valid. I don't bother using form validation like this, it's too much of a pain in the ass. Rely on your other security methods to secure the session as a whole. PHP (and the web in general) is stateless. There is no "flow". Don't try to arbitrarily enforce one, it ends with this kind of unsolvable problem. As for the whole "what is the session ID" question, which is a few paragraphs: You don't ever have to know what the session ID is. Until you start writing your own session handler or changing fundamental behaviors of the session in general, you don't care about the session ID. You don't have to validate it, you don't have to pass it anywhere, you don't have to manually set it, you just trust that session_start() always establishes a session, using an existing one if available. Sessions are maintained by cookies, so while technically "they are passed with GET or POST" is true, it's actually part of the communication header itself, and is processed by the web server. The session comes through on all communication from the browser, including ajax calls. Yes, the sessions are automatically destroyed by the OS and/or by PHP, so if you close your browser, and someone else uses your session ID two hours, it's possible the session file was destroyed. However, session cookies are never stored on your hard drive, so it would be difficult, if not impossible, for someone to hijack them like that. Almost always. Some database technologies make pagination really unreasonably difficult, but for the most part as long as you use LIMIT clauses, you're fine. SSL has nothing to do with it. GET does not show the session ID. Anything you see with ?sessionid= in the URL is 5+ years old and should be disregarded. It's no longer a recommended method. The session ID is included in the communications headers alongside the message, it is not part of the message itself. Use POST for POSTing data, and GET for links and GETing data. This is the most commonly invented "solution" to man in the middle attacks, but it doesn't think about the asynchronous nature of the web. What if you make a page which contains ajax calls, and the user makes two simultaneous ajax calls AND submits a form at the same time? You'd log them out. Session garbage collection is built into PHP and you don't have to worry about it. If you move your session directory back to /tmp, then the OS will also clean up old sessions. Yes

Dergam, I wasn't attempting to scold you. The phrasing lead me to assume something about the way you were thinking about the problem. If you were thinking incorrectly, it would be good for you to think a different way so you could easily solve the problems. Good that you got it working, and keep at it! you're welcome here.

First of all, I really love this post. It was really well written and I appreciate someone who tries not to ask for handouts. This is all fine. Overkill, actually. Good for you. SQL Inection is prevented through either PDO bound parameters, or by wrapping all string inputs in mysql_real_escape_string and all numeric inputs in floatval. There's more to the theory, but that's the baseline answer. The session ID is always valid as long as the temporary file still exists. The security problem is usually session hijacking. You can prevent that by either going full SSL (like facebook did) or by storing user-agent and IP in the session and validating it every time. Rotating the session ID on every page load is a tactic used by the super-paranoid who believe man-in-the-middle attacks are likely and not just possible. I'm not saying it's a bad idea, but it feels like overkill. The session works like this: - You call session_start for the first time - A temp file with a random name is created - A cookie called PHPSESSID (or the cookiename set in php.ini) is added to the header, with the value of that cookie being the name of the temp file - Anything you add to $_SESSION is serialized in a custom format and stored in the file - That file is unserialized every time session_start is called thereafter, and placed into $_SESSION. session_start checks for the existence of the session id cookie, and will either create a new session, or load an existing one No data in the session is passed to the user, it is completely safe unless you purposely echo session values (or the server is compromised, obviously). You can rely on POST data up to a point. It CAN be tampered with. If you really want to secure your post forms, do this: -Hash the microtime and username of the current user -put that in a hidden form field -put it in the session -when the form is submitted, compare them Note that this tactic will stop your site from working in multiple tabs at once, as the session is global for the whole browser window. If you're really this concerned about your sessions, simply switching to straight SSL for the whole site would solve all your problems. The rest is just thought exercises, and none of them are 100% secure. It's like home security. Installing steel plates over your windows is 100% secure. The rest is just locks on a piece of glass. But steel plates are expensive and ugly. If anything else is still confusing, let me know.

What is the problem here? Converting this to PHP is as easy as adding punctuation: if ( $current_bid < $reserve ) { //bids too low } else { $current_bid = $high_bid; $c = $Data['ends']; } Of course, this assumes a LOT about your structure and code layout. If your question was "write an auction house script for me," then we're not going to do that.

Note that your thread title fell into the classic trap of new programmers. You said "special characters don't work." That's not the problem. The problem is "I don't see special characters when I expect to see them." The problem is that you're viewing your output incorrectly (in a browser, rather than plain text), not anything to do with PHP. Make sure you define the question properly, it may help you understand a way to fix it on your own.

Because the user clears their session cookie after posting and/or is using a bot.

This site is powered by hundreds, if not thousands of files. Index.php, if it exists at all, is a router file which includes the appropriate files for what you're attempting to do.

Explain more what you mean by "file"? Do you mean one enormous 10mb PHP file that runs the entire forum? Or are you talking about using files instead of databases?

That's a standard error message, your code may not have had error reporting turned on before. A more correct version is: <?php if ( isset( $_POST['Afloop_dag'] ) && $_POST['Afloop_dag'] == "1") { echo "selected"; } ?> -Dan

Err...barand has a great point. You already have the user_id. Don't query at all.

1) The manual page for mysql_query shows you exactly how to do this 2) If you're using the results of one table to query another, you'd be better off writing a JOIN query.

both for and foreach would work here.

Dude, you are killing me. You have to read the manual chapter on arrays. You have to. The array is PHP's strongest and most powerful feature. The short answer is: You access the cart just like you would any other array. The line I gave you is putting that information at the end of the array in $_SESSION['cart'][$productId].

Like this. This is exactly what I suggested, it was 20 lines counting comments: <?php function addToCart ( $productId, $quantity, $size, $color, $price ) { //if the productID doesn't exist, just create it: if ( !isset($_SESSION['cart'][$productId]) ) { $_SESSION['cart'][$productId] = array(array('quantity' => $quantity, 'size' => $size, 'color' => $color, 'price' => $price)); return; } //product already exists, check to see if it's the same as another in the group: foreach ( $_SESSION['cart'][$productId] as &$product ) { //NOTE: If you want to override pricing with new tiers, you can remove 'price' from this comparison. You may also want to // fetch prices from the database when you DISPLAY the cart if you do bulk discounts if ( $product['price'] == $price && $product['color'] == $color && $product['size'] == $size ) { $product['quantity'] += $quantity; return; } } //if we've reached here, the productID is already in the cart but the current item is not a duplicate of an existing one: $_SESSION['cart'][$productId][] = array('quantity' => $quantity, 'size' => $size, 'color' => $color, 'price' => $price); } //TEST CODE //set up the cart: $_SESSION['cart'] = array( '123' => array(array('quantity' => 2, 'size' => '10x10', 'color' => 'blue', 'price' => '899.95')), '456' => array(array('quantity' => 1, 'size' => 'Large', 'color' => 'green', 'price' => '9.95'), array('quantity' => 3, 'size' => 'Small', 'color' => 'black', 'price' => '8.99')), ); echo "<pre>\n\n"; print_r($_SESSION['cart']);echo "\n\n"; //add a new green large 456: addToCart('456', 1, 'Large', 'green', 9.95); print_r($_SESSION['cart']);echo "\n\n"; //add three different sized 123 products: addToCart('123', 3, '5x5', 'blue', 499.95); print_r($_SESSION['cart']);echo "\n\n"; //add a completely new product offering: addToCart('789', 30, 'Refill', 'yellow', .90); print_r($_SESSION['cart']);echo "\n\n";

The word "donate" has serious tax ramifications, and falsely labeling something as a donation is fraud. I am not a lawyer, of course, but that's the truth. Now, as for the rest of your idea: If a credit card number goes onto the page, that page must be https. you must buy an SSL certificate and have a secured server. That's the law. Again, not a lawyer. Your client wants to make an online store which does not handle shipping. That's fine, hooray, good for them. That website, if it accepts credit card numbers, has to be secure.

Didn't we already do this in your last thread? What's the problem? Where are you stuck?

xyph's solution is perfectly correct. However, I recommended the session because I figured you'd need the userID throughout your site for login and permission checking. May as well put it in the session now.

I don't know, that's a business rule. What do you want to happen when they do that? If I bought 3 green shirts at $9.99, then 15 red shirts at $8.00, would you really make an entry for 18 shirts? How would you ever figure out the original order? If it were me, I'd probably use the same idea I gave you earlier, except $_SESSION['cart'][$productId] would be an array of products, each with their own quantities and specifications. if all specifications matched, I'd update the quantity. If any one of them did not match, I'd add a new row. Obviously, if $_SESSION['cart'][$productId] didn't already exist I'd add a new array of products, like this: $_SESSION['cart'][$productId] = array( array( 'quantity' => 5, 'price' => 9.99, 'options' => array( 'color' => 'green', 'size' => 'medium' ) ) );

If the customer stays on the site, that site must be SSL for the payment acceptance screen. I believe that's federal law. If it's not, it's just common sense.

When you go to add a product to the cart, check to see if it's already in the cart. if it is, only update the quantity.

Well go back a bit. You don't need to buy an SSL certificate to communicate with AuthorizeNet. That was your question. You still need one to accept payment information. Now you've changed the question to be about communication between you and your users.