Psycho

This topic has been moved to PHP Regex. http://www.phpfreaks.com/forums/index.php?topic=358363.0

<< Moving to the Reg Ex forum >> I'd make one clarification to silkfire's explanation. The #3 condition is logically an optional condition since it matches 0 or more characters. In other words, there do not need to be any characters between the number "1" (item #2) and the subsequent newline for item #4. So, the regular expression would also match the following in red: 0+432jkrouwer{€$@£$@^??423 1 -iodfugo89042432purewrwerpuwer Also, to simply state the expression in English, it matches any line that line that starts with a 1 followed by a line that starts with a dash.

Not any that are fully thought out. But, I really think they would be a big waste of time. But, here goes. In your desktop app create some function/process that generates a hash using a salt. This would need to be built into the application files such that it could not be reverse engineered (at least not without a lot of work). Then for every request from the client grab a timestamp and run it through the hash and send the timestamp and hash along with the request. The server could then take that timestamp and run it through the same hashing process on the server and check if it matches the hash that was sent. But, this also raises problems. A malicious user could just grab a single timestamp and hash and send the same values on every request. You can't reject requests because the timestamp is X minutes old or something similar because people could be in different timezones. But, you could possibly track requests from the same user via session data. if the requests aren't changing the timestamp reject them. No matter what way you slice it thre really is no good solution. There will always be a hole in the system that requires some other "patch" which really doesn't eliminate the problem entirely. You are trying to fix something that doesn't need to be fixed and will only cause more problems than you think you are addressing (IMO). You shouldn't care where the request is coming from as long as the data is valid.

There is no reason to store that information in a cookie. In any event, you say that the correct value is displayed after you refresh the page. If you are trying to set the cookie AND retrieve it on the same page load that is your problem. When you set a value in a cookie, you cannot retrieve it until the next page load. http://php.net/manual/en/function.setcookie.php If that is your problem then there really is no problem. There is no reason to unencrypt the value you just encrypted since you have the original value in that same instance of that script.

How is that going to help? The user can ascertain the encrypted key the same way they can get the unencrypted key and you have no way to determine on the server-side if that encrypted key was sent by the application or not. So, it doesn't matter if the user knows what the actual key is as long as they are sending the same information that the the desktop app would send. I can think of some alternative approaches that would make it somewhat more difficult, but none of them are foolproof and would only add more complexity (i.e. bugs) that really adds no value. Again, I really don't understand what you are trying to prevent. The statistics should be logged on the server based upon the requests from the client. And, as I stated previously, the services shouldn't care what or how the requests are sent only if the requests are valid or not. There are some $_SERVER vars that would identify the client-side app, but those can be easily be spoofed by someone who has gone to the trouble to find the key anyway.

$deleteID; //The id to be deleted passed from POST $cartArray; //The array of products passed from POST //Get the key by searching for the ID in the array $deleteKey = array_search($deleteID, $cartArray['prodid']); if($deleteKey !== false) { //Remove the element from each subarray foreach($cartArray as $index => &$values) { unset($values[$deleteKey]); //Uncomment this line if you need to reindex the values //$cartArray[$index] = array_values($values); } } Note, if the array was more logically structured you could delete an item with a single line of code instead of all that

Well, with your current format, which I don't link, all you need to do is identify the key of the selected ID for deletion then delete each record with that key in the subarrays. Note that this will not re-index the keys. So, if you have keys: 0, 1, 2, 3, 4 and then delete key #3 you will be left with 0, 1, 2, 4. However, you can reindex the keys if needed. I will post some sample code shortly.

I agree. What is your exact process for editing the cart. Typically the cart will be stored in a cookie or in the session. So, if the user is editing the cart you only need to pass the changes. It looks like you are passing the entire cart when the user wants to delete an item AND you are not passing any identifying information for the item being changed. But, there is definitely one thing you should consider changing - the format of your array. You have sub-arrays which contain different information about the products. A better format, IMHO, is to have one sub-array for each product where the ID of the product is the key for the sub-array. This is a much more logical approach. The problem with the current approach is it assumes that the first element in the 'name' subarray necessarily matches with the first element in every other array. This would likely be true, but that kind of loose logic can cause problems.

If this is your code then you should be able to post JUST the relevant code. Simply dumping a bunch of code here puts the onus on us (those providing free help) to try and decipher the logic and pinpoint the problem. But, looking at your code I am seeing issues that make no sense. Take this for example $query_count = "SELECT COUNT(*) FROM `CysticAirwaves` WHERE `FromUserID` = $auth->id AND date = `CURDATE()`"; $request = mysql_query($query_count,$connection); $result = mysql_fetch_array($request); $query = "SELECT COUNT(*) FROM `CysticAirwaves` WHERE `FromUserID` = $auth->id AND date = `CURDATE()`"; $result = mysql_query($query, $connection); $post_count = mysql_result($result, 0); It looks like you are running the same query twice. Why? While that would not specifically cause the problem you are describing, if you can't clean up the code to not be running the same query twice what other problems are there that would? You have a ton of nested if/else statements which is usually unnecessary to that level and only adds complexity. You should draw a flowchart on paper and then code to that. Anyway, you should only get that message if ($post_count >= $max_posts_per_day) So, for debugging purposes you should do a var_dump() of those two variable to verify what they are. Second you should echo the query to determine the number records to the page to verify it "looks" right. If so, run it through your database admin utility (e.g. PHPMyAdmin) and verify it is returning the results you expect.

OK, let's recap. You do not want any user to be able to use any feature as often as they wish. There will be no manner of authenticating/identifying the user. You desktop app is using a "key", but from what it sounds like, you are only using that key to identify that the request is coming from the desktop app so you can prevent requests from being submitted in an alternative method. And your "problem" is that you don't want someone to identify that key and make submissions outside your windows app. So, my question to you is - what do you care how someone makes a request? You should already have the necessary validations/sanitizations in place to prevent problems. Many web-based apps are built such that anyone can build a custom front-end interface. You do say that you are worried about people "filling up your database". Couldn't they do that using the desktop app anyway? It is just as easy to create an automated script for the desktop app (if not easier) than it would be to create custom scripts for generating the requests independent of the desktop app. So, if your real concern is about someone sending too many requests you should still consider some way to limit the rate/number of requests per user within a given time frame - e.g. no more than 20 requests per minute or whatever you determine would be.

You are not making sense. You first talk about accessing remote files then you end with talking about the database. One is not related to the other. In any case, you should have some way to "authenticate" the user which does not have to be a traditional username/password login. You should never rely upon obfuscation for security. If this is a desktop application that is integrating with your web back end you could do something where each user/firm has an account number. Then only allow the user to work with files/data associated with their firm. If there is no control of who can use the application then you would want to implement some type of limiter to prevent the same user from processing "too much" data either downstream or upstream.

Why on earth would your DB password even be exposed between the client and server? If you are talking about a username/password for logging into your application you would only submit that information once and then store a token in session data to persist that user as logged in. However, you will need to pass the password in plain text when the user submits their log in credentials. The only way to effectively protect that would be to use https which requires you to set up certificates and probably coordinate with your host.

It sounds as if you are wanting to implement some AJAX for the ability to select the 'correct' answer. That allows someone to select the right answer without having to refresh the page. That's a great idea. But, first I would suggest building the functionality using a button that is a form and have the form post normally. I.e. have the page refresh and do any back-end processes then redisplay the page with whatever updated information you want. Once you have that working, THEN implement the AJAX so you can do the same thing without a page refresh. Trying to do both at the same time can create difficulty when debugging. However, regarding the ability to extract the movie poster from IMDB is something that I will not, nor anyone else on this forum should, help you with. What you are asking to do is referred to as screen scraping. That is something that violates IMDB's Copyright / Terms Of Use: http://www.imdb.com/help/show_article?conditions

I didn't check all your field names, but 'call' is a MySQL reserved word. You can either change the field name or enclose the reference in back quotes. Also, you should REALLY be validating/sanitizing user input before using it in a query // Get values from form $name = mysql_real_escape_string(trim($_POST['name'])); $company = mysql_real_escape_string(trim($_POST['company'])); $phone = mysql_real_escape_string(trim($_POST['phone'])); $mobile = mysql_real_escape_string(trim($_POST['mobile'])); $email = mysql_real_escape_string(trim($_POST['email'])); $call = mysql_real_escape_string(trim($_POST['call'])); $patch = mysql_real_escape_string(trim($_POST['patch'])); $user = mysql_real_escape_string(trim($_POST['user'])); $sql = "INSERT INTO $tbl_name (`name`, `company`, `phone`, `mobile`, `email`, `call`, `patch`, `user`) VALUES ('$name', '$company', '$phone' '$mobile', '$email', '$call', '$patch', '$user')"; $result = mysql_query($sql);

Well, simply echoing "ERROR 1" isn't providing much help now is it? Why don't you echo something that will provide some actionable information: if($result) { echo "Successful<BR><a href='insert.php'>Back to main page</a>"; } else { echo "ERROR 1<br>"; echo "Query: {$sql}<br>\n"; echo "Error: " . mysql_error(); }

Ah! It works! God bless your cotton socks! This has been giving me a headache and I was sure i was reading it right, I thought it said the file path was the URL... Well Much appreciated! Yeah, the manual sort of sucks on that one particular point. I didn't see any reference of what the web path was in the setup. But, I say the web path mentioned when enabling web space for users. So, I just modified that one to what would seem logical.

The function will never run because the variable $submit is never defined. I think you mean to use if(isset($_POST['Submit']))

Using my computers browser and opening them from the file location. e.g "\\diskstation\web\insert.php" Is that the FILE path or the WEB path? You can't simply load a PHP file in your browser and expect the PHP code to be parsed. You have to request the file from the web server path. EDIT: The manual is a little vague, but it looks as if the "web" folder is the FILE path. And, I think you need to be accessing the file using http://Synology_Server_Name/filename.php (assuming the file is in the root of the "Web" folder)

How are you accessing the pages via the browser? Are you accessing them through their file system locations or are you "requesting" them through the built-in web server? Also, did you enable the web services in the configuration for the device?

Are you using PHP short tags or full tags? You shouldn't be using short tags (unless the documentation for that device states you need to)

Can you provide an example of a sting that is causing you a problem along with the code in question.

Where is your current code? After all validations pass and you perform any login tasks (e.g. set session variable) I would then use a header() to redirect the user to whatever page you want them to be on.

I didn't notice that I simply worked off your original query. CURDATE() should not be in any quote marks. $query = "SELECT COUNT(*) FROM `CysticAirwaves` WHERE `FromUserID` = $auth->id AND `date` = CURDATE()"; If you are getting a white screen then this code is not being run, because the debug message I put in there should be displayed regardless. So, the error is likely in some code before this one.

$post_count will be a string that contains a numeric value - not an array. What does "to no avail" mean. Please provide exact results, error messages, etc. Anyway, give this a go $max_posts_per_day = 5; $query = "SELECT COUNT(*) FROM `CysticAirwaves` WHERE `FromUserID` = $auth->id AND date = `CURDATE()`"; $result = mysql_query($query, $connection); $post_count = mysql_result($result, 0) or die(mysql_error()); //Debugging lines echo "Query: {$query}<br>\n"; echo "Post count for user id {$auth->id} is {$post_count}<br>\n"; if($post_count >= $max_posts_per_day) { echo "You have reached the maximum number of posts for the day. Try again tomorrow"; } else { $comment = mysql_real_escape_string($_POST['ProfileComment']); $query = "INSERT INTO `CysticAirwaves` (`FromUserID`, `ToUserID`, `comment`, `status`, `statusCommentAirwave`, `date`, `time`) VALUES ('{$auth->id}', '{$prof->id}', '{$comment}', 'active', 'active', CURDATE(), CURTIME())"; mysql_query($query, $connection) or die(mysql_error()); }

Ok, what IS it doing? Are you getting any errors? What debugging have you done to see what is happening any why? I was going to ask, what kind of field is "date" is it JUSt a date field or is it a datetime/timestamp field? If it is a datetime/timestamp field then the query will always return 0. I also see that you left in your old query which is being run unnecessarily.