maxxd

The browser is forwarded to a target page upon successful login - that's where I'm checking to make sure the cookies are set. Sorry - that's in the JavaScript that I totally forgot to post. $('#login-popup #submit').click(function(e){ e.preventDefault(); $.ajax({ type:'post', url:myVar.ajaxUrl, data:{ 'action':'agent_login', 'username':$('#login-popup #username').val(), 'password':$('#login-popup #password').val() }, }).done(function(ajaxObject){ var resp = JSON.parse(ajaxObject); if(resp.success == true){ clearLogin(); window.location.replace(resp.location); } }); });

Hi y'all. It's been forever and a day since I've dealt with cookies, and I can't get through the cobwebs in my brain about them. I know that cookies have to be set before any output goes to the browser, but if I'm not mistaken, it's the same with sessions and sessions work in this situation. Unfortunately, the client needs cookies for integration with an existing piece of software. Basically, what's happening is this: You load a page, click the 'login' button, which uses JQuery to change the display on the login screen from 'none' to 'block'. Use the newly-visible login form to enter username and password, which are passed via ajax to my login function. If the login is successful, I set the cookie variable and redirect the user to the protected page. However, despite the ajax reporting a successful login and redirecting the browser as expected, the check on the protected page is kicking the user back to the beginning because the cookie was never actually set. FunctionsClass.php: /** * Logs in the requesting user with the agent and email values supplied via AJAX. * @return string JSON-encoded array */ public function agentLogin(){ $ret['success'] = $this->_site->login($_POST['username'],$_POST['password']); $ret['location'] = '/protected-page'; print(json_encode($ret)); die(); } Site.php (that's $_site in FunctionsClass): /** * Logs in the agent. * Checks to see if the user is already logged in, if not, attempts to do so. * @param string $un username * @param string $pw password * @return boolean */ public function logIn($un, $pw){ if($this->isLoggedIn()){ return true; } return $this->logAgentIn($un,$pw); } /** * Check to see if the cookie set so we know if the user has logged in. * @return boolean */ public function isLoggedIn(){ // return !empty($_SESSION['mycheckvariable']); return !empty($_COOKIE['mycheckvariable']); } /** * Log the user in. * @param string $un username * @param string $pw password * @return boolean */ private function logAgentIn($un,$pw){ // $_SESSION['mycheckvariable']['email'] = 'me@notmyemail.com'; setcookie('mycheckvariable','me@notmyrealemail.com',time()+60*60*8,'/'); return true; } It's not as though I'm even actually checking a database - just trying to stub this out for client presentation. And, if I uncomment the two lines using sessions and comment out the cookies, it all works perfectly. I'm not at all sure what I'm missing and would very much appreciate some other eyes on this - any takers? I'm using WordPress, if that matters at all... Thanks in advance!

You need to remove the check on $_GET['confirm']. The above changes (marked in red) should work - I've not tested them or had my second cup of coffee yet, so no guarantees, but that should do it. I'm assuming that $mid is being validated and sanitized at some point before your switch statement. As a side note, switch from mysql_* to PDO and do the DELETE and UPDATE statements in a transaction so you don't end up with orphaned records.

Just because you're not getting the errors doesn't mean they're not happening - production servers typically do and should suppress error display - the user doesn't need to know that much about your server set-up. Granted, you should be seeing your fatal error. Have you used session_start() to actually start the browser session and have you defined the constant $site_url in the config class before attempting to use either $_SESSION['role'] or config::site_url?

You don't. What Frank_b is suggesting is putting your included scripts above the web root, where the user can't access them anyway. Anything above the /public_html/ directory (in this server set-up, sometimes it's called /www/, sometimes it's /html_docs/) is inaccessible from the internet. So, by using something like require_once('../includes/IncludedFile.php'); from your /var/user_directory/public_html/index.php script, you'll be accessing /var/user_directory/includes/IncludedFile.php, and can use the functions or class in that script in your display file. Of course, Frank_b was recommending an absolute server path to the includes directory instead of the relative that I typed.

For the sake of others having similar issues in the future, let's keep the discussion in the thread. Read up on PDO here. You'll want to look at the __construct() function I directly linked to, as well as prepare(), bind(), query() and execute().

The variable $db isn't instantiated anywhere before you try to use it. You'll need to create a $db object using the credentials you put in the $dbConnection array. Also, please use code tags when posting code (the '<>' button on the editor).

One more thing I just thought of - when you say nothing is being returned, do you mean you get no data, or you get no output at all? I'm pretty sure that jcbones' observation should have thrown an error because the referenced array index doesn't exist, but if you're not getting that, then you need to turn on error reporting.

If you run the query directly, does it return the expected results? In other words, are you sure you have a record with the id 62 in the database?

tsangaris, while I'm sure it couldn't hurt, I'd think it more important to make sure at least the sender and recipient IDs are legit, active IDs in your system before sending anything. Keeping the processing php script in a directory above the web root won't immediately make it safe, but it does make it a bit more difficult to call the file directly from outside your server. You should probably create a nonce in the source form html, store it in session, pass the value from the form with the other values and check that in the processing script to make sure that the request is coming from your form and not somewhere else. This doesn't mean a human being isn't logged in to your site sending bad messages, but at least it means you can be a bit more sure of the fact that request originated on your site. And, of course, sanitize and validate any and all data supplied by an end-user. Or another system. Or anywhere, really.

OK - now we're getting there. It sounds like you're on the right track. Using radio buttons and associating each possible recipient's id to the value attribute is exactly how I'd go in this situation. Pass the user-defined information (recipient(s) and message) via AJAX, but keep the system defined information (your sender's ID) in $_SESSION. That way you're not mucking about too much with the session data and, more importantly, when you go back to the code in six months to a year, you can clearly follow the data chain. In addition, you can then move and repurpose the AJAX script without having to worry about any hard-coded $_SESSION calls. Think of it as decoupling the script from the site.

OK - you're having an issue before the ajax call, right? So how is the sender (userA) selecting a recipient (userB)? If they're typing a name into a text input, you can use the value of that text input in the sendmessage.php script to find the ID. If you're using a select element, the ID (or a proxy) should be printed directly into the markup as the value of the option element - main.php (or another script that's calling main.php to get the data) is going to print userB's id in the option element value. You'd then send that with $('#recipientSelect')val() from the JS to sendmail.php. UserA has to be logged in to send a message, right? If so, I'd think you'd have their user ID in session and can grab that in sendmessage.php without having to define it in the javascript at all. And obviously the message value is the $('#message').val() of the message text area. Is that the question you had, and if so, does that make sense at all?

Basically, your data entry form can be a separate page. Your opening tag for the form should look something like this: <form name='myForm' action='processMyForm.php' method='post'> where the code we've been discussing above is in the file processMyForm.php. Check at the top of that file to make sure the $_POST[] variables that you're expecting are set. If they are, do what you need to do to the values to make sure they're safe and in the format you're expecting, then run the query using those values. If they're not set, you can redirect the user to the form page or display an error or play a fun sound clip or whatever - you just won't be running the query. That's the easiest way I can think of to handle it - there are many other methods, but you gotta learn to walk before attempting to run.

My pleasure - let us know how it goes and if you run into any problems, just ask!

Use JQuery.ajax() functionality to handle passing the variables to and from your php script via either $_GET or $_POST methods, depending upon your preference and the amount/type of data you're dealing with.

First off, don't use that code. The mysql_* functions have been deprecated in php for about a decade and are slated for removal at some point. I know it'd break a lot of the internet, but I do wish they'd just remove the darned things already. What you want to do is read up on PDO by following the link I put in my last post. You'll create a new PDO object with your database credentials, query the database for the information you're looking for and use the returned data to populate the table you're building. You can do that last part by combining your last two scripts into one. <?php $connection = new PDO(/* credentials */); $sql = $connection->query(/* query string */); $returnArray = $sql->fetchAll(PDO::FETCH_OBJ); ?> <table> <thead> <th>Company <th>Price <th>Location <th>Review </thead> <tbody> <?php foreach($returnArray as $return){ ?> <tr> <td><?= $return->comapny; ?> <td><?= $return->price; ?> <td><?= $return->location; ?> <td><?= $return->review; ?> </tr> <?php } ?> </tbody> </table> I have neither tested the above code nor had my second cup of coffee yet this morning, so understand that this is not a copy and paste solution. However, it should point you in the right direction. Once you get to this point, post back here if you're still having problems. Also (and a bit off topic) don't use 'date' as a column name. I thought it was reserved, but a quick search shows me that it's not. Hunh. However, it is a MySQL function and can make things confusing.

It's brute force, but glad it worked for you.

If I'm reading this right, you're asking how to get information from the form into and out of the database, yes? If so, you'll need to look into PDO for database functionality. I'm assuming you've already got the database set up - if not, that's going to have to be step one, obviously.

I ran into a similar situation at one of my jobs a while back. Neither htmlentities() nor htmlspecialchars() with ENT_QUOTES would correctly handle fancy quotes. I think I ended up using str_replace() for opening and closing fancy quotes, opening and closing fancy single quotes, and something else that won't quite come to mind right now.

Turn on error reporting. You've got output to the screen before your redirect call, which won't work. The reason you're seeing the form before it sits there is because the form is the output to the screen that's causing your script not to work.

Given your hand-coded error message, I'd venture a guess that neither resource.serviceName nor resource.resourceName are set, and resource::insert() doesn't exist in the $methods array. Also, in the future please use the code tags (< > in the toolbar) when posting code as it does make it easier to read. Yours wasn't bad, but it's a good habit to get in to.

Actually, it's not a bad way at all to think about it (admittedly, it's exactly how I'd set it up so I might be a bit biased). Basically, if you're looking at base functionality, look in the BasicProductPdfWriter class. If it's something specific, look in the specific class. The worst that'll happen is that a developer will start by looking in the specific product class and get referred up the chain to the more general class - you're not so much trying to understand 6 different classes, you're trying to understand 1 class and some very specific differences. The reason to use the interface is not only to ensure a consistent api, but to make the polymorphism transparent. By type hinting the interface in your object methods you can pass the basic writer or any of the specific product classes like so: public function doSomethingCool(IProductPdfWriter $writer){ $writer->add($pdf,$neatStuff); } $writer can then be an instance of ProductAPdfWriter, ProductBPdfWriter, BasicProductPdfWriter, etc. and the method will accept it.

Also looks like you're missing a comma after meter_multiplier on line 5. Any reason why you're selecting meter_multiplier twice (once on line 5, again on 6)?

Make sure you've got error reporting turned on: error_reporting(-1); ini_set('error_display',1); As to the actual cause of your error, it looks like you're trying to go from mysql_* to mysqli_* (which is good) by adding an 'i' to the end of the 'mysql' in the function calls and expecting it to work (which is bad - it won't). Check http://us2.php.net/manual/en/mysqli.query.php for information on how to use query(), and unless I'm mistaken there isn't a mysqli_fetch() function...

Also, check your page source. I could be wrong, but I bet the esc_attr() call is encoding (or possibly just adding a slash to) the quotes around 'checked'. Either way, chances are that'll break it.