gizmola

It's right in the acronym, although the X is a bit tricky. Cross (X) Site (S) Scripting (S). Break it down: "Cross Site" I'm on your site, but somehow I ended up running code from another site. "Scripting" -- ie. it's javascript/clientside code that is executing.

Ok, so now that the "mystery" is resolved, I will opin about what you really wanted all along. SELECT EmployeeNumber, count(*) as countOf FROM cat_completiondate WHERE CategoryJobPosition = 1 GROUP BY EmployeeNumber, CategoryJobPosition

So it seems you have a fairly common database structure. What is it exactly, that you can't figure out.

Against my better judgment, I will go ahead and provide you advice. I should probably start with an analysis of your approach here. It requires improvement, if you would like to be taken seriously and accepted or respected. This could be a major step in your personal journey, if that journey includes as a goal becoming a competent PHP developer. To put this bluntly, you have no credibility on phpfreaks, based on your participation since you started coming here. Your posts reflect a general lack of expertise in web development, and you have further detracted from your reputation here by being argumentative and close minded when people attempted to engage you. Truthfully, the world doesn't need a forum written by you, however, I fully endorse any attempt you might make to get in over your head, as it has the potential to be a great learning experience for you. - Features/ Requirements You need to have a feature list. Where is your list? -Technical design This would outline a technical philosophy, and architectural decisions -Entity relationship diagram Your database design -Competitive analysis Have you installed, played with and analyzed the various forums that already exist? I know the answer to all these questions. You haven't done anything yet -- this is just a whim -- some more digital graffiti on the wall of our sandbox. People who want to write a forum don't bother posting to a forum first -- they do some actual work. It's great to ask for an opinion on a straw man, design doc, asset, or code library. Feel free to come back when you have any of those. Until then, I will continue to consider your presence here to be borrowed time. You should probably know that you have already managed to annoy some very knowledgeable people to the degree that they already ignore you, and you've gotten to the level of notoriety that you may find yourself persona non grata if things don't improve.

So, what is the OS of the current server and what was the OS of the old server? Is it possible you moved files back and forth from unix to windows? This smells a bit like a line ending issue or something of that ilk. Can you shell into your new server and open the session file with vi and make sure there's not something odd in there?

I understand you had the best intentions -- it's just that the approach you've taken thus far is already hard to read. It seems you have the basics, and you can certainly build upon it, although at present I'm not even sure I know what your current problem or bug is. I did take a look at your site, and if this is going to be a database of pythons, I don't know that the people who would fill that out are really going to be all that upset if they have a bunch of columns to fill out -- in fact, you may find that you piss people off more, by trying to hide a lenghty multi-form approach. At the end of the day, you will need to validate the input before you accept it, whether you have 5 interconnected forms or one big one. Just my 2 cents. If you have a specific question, I'd be glad to take a look at it, as would others. I think we lost the thread on what your exact problem is at the moment.

You have started off strong here, and are just getting stronger. You don't know jack squat about PHP, armed with an obsolete script you didn't write, about which we have no information, and then start arguing with the experts here, after they've explained to you the reasons the thing doesn't work. You haven't provided a line of code, or even a link to the script you grabbed, but then have the nerve to start telling us there's no alternative. Speaking for myself (and I know for many others here who actually know PHP) I don't want to help you fix your problem with this one script, because this problem is going to exist on page after page, and we don't want to spend our time wading through all the posts you'll inevitably be making. Here's a novel approach for you -- how about doing some of your own legwork and reading up on the register globals setting and how to turn it on? Maybe there's another forum you should go to, begging for help, instead of this one. The truth is, that this forum is one of the most welcoming to php noobs, often too welcoming, so you probably will find that your approach is met with far less friendlier responses, than what you've received here.

So, the first thing I wanted to state up front was that it does indeed sound like a database would be very beneficial to you. If you can't use mysql, you might be able to use an alternative like sqllite or even bdb (berkeley db). There's just a huge advantage to having structured data and indexed retrieval available to you. I'm not sure what you're paying, but I know of all sorts of $6/ month shared hosting companies that give you a full LAMP stack as well. So on to the bad news -- being that I perused your script, and quite frankly it already borders on spaghetti. Doing naming based on page numbers in a multi-form process is just asking for trouble -- what happens in the future when you realize that page 2 & 3 should be combined, page 5 eliminated, and page 7 updated? You will regret that I predict. I don't have the time or patience to go through and start rewriting code, but I think your best bet would be to begin by asking yourself why you are trying to make something so complicated. Is this really something that can't be done in one single form? Javascript is also very helpful for linking things together, especially if the interrelated choices are going to be static.

Care to explain how a flat file is a database, or what the inherent security issues that you are claiming are related to SQL are?

Yeah, I would consider just passing the data back. This certainly works fine, as people do it all the time with dynamically generated files, such as using the gd library to create an image. With that said, I think we identified the issue with the file opening mode, and fpassthru should work for you, so you can go either way with it.

It's funny, I keep hearing things like that, but never in my life have I experienced an ISP here with dynamic IP address allocation if we disregard the dial up era. This is quite common in the US. Sadly there are still lots of people using Earthlink and AOL, not to mention people at corporations who sit behind a proxy. Just a case in point, I have multiple friends here in LA who have Verizon DSL. The router does a CHAP auth, and the lease on the IP is set so that they have to reauth every so often, and whenever it does this, the IP changes. It's not at all unusual for people to get broadband here, and plug directly into their PC. These people often turn off their equipment every day, and the result is -- new IP. My mom has Comcast cable modem, and her IP stays the same for months at a time, but if the cable modem is reset, the IP changes. With that said the biggest reason that IP's need to be looked at carefully is that ubiqitous NAT means that many users can have the same IP.

I'd highly recommend a decent tutorial on SQL. $sql="SELECT * FROM data WHERE id

Most of that sounds ok -- only the IP is an issue. IP is dicey, because with big ISP's IP's can change. You certainly wouldn't want to make sure that the IP is the same with remember me, as 99% of your users will no doubt have dynamic IP's that can change from day to day or hour to hour, depending on the ISP and their behavior. What does make sense is that, if you want to implement this checking, you can see whether or not the IP address has changed for an active session. The very presence of the remember me feature, will however, in essence need to disable the check, since remember me needs to supercede checks inside the session, and reset the internal authentication state, which would need to include the last IP.

The other thing about sessions, is that they get cleaned up based on the amount of people using the site, and some arcane variables in the php.ini. It's best not to have a mix of sessions --- have your settings be the best fit for your website and stick with that. People often get confused about the difference between a session and a login -- they are not the same. A login is an application state on your site. It often gets facilitated by sessions, but the best way to think of it, is that every visitor is most likely going to have a session started, whether they have sucessfully authenticated themselves or not. A "remember me" function can be many things, but one of the best solutions is to do as PFMaBiSmAd recommended and set a completely seperate cookie variable that indicates that they would like your site to bypass the normal name/pw authentication. So clearly what you need to do to facilitate this, is add code that looks for the presence of the cookie, matches the person up, and in essence authenticates them. For this reason, a hash is a good solution, because it should disclose nothing about the user. For this reason a good md5() or sha1() hash of your construction will do the trick, but additionally, you need to alter your user table, so that this hash can be used to lookup which user it pertains to. The hash in essence becomeas a SUBSTITUTE for the user entering the name/pw. Now the topic of the relative security of this approach was brought up before, however you have to realize that sessions by default use cookies as the enabling technology (which is actually preferred in most cases), so a person getting their hands on a cookie file, is instantly able to masquerade as a user. This isn't really as bad as you think, because again, it is no different than if someone was to look over your shoulder and watch you type your username and password. As pointed out, unless the entire login is protected via SSL, anyone sniffing traffick will be able to see your name/pw in clear text, but in many applications this is The issues involved have a name: "session fixation". You can read up on this problem, and potential solutions. Best practice is to regenerate session ID's whenever a user attempts to "escalate privileges", and this would include a user wanting to change their password, or advance to an admin role, or whatever else you deem risky. It also explains why changing a password typically involves requiring the user to enter their existing password first.

I just perused the fpassthru docs, and it stated that you probably would need to rewrite() the file, so it looks like your code might work, but you will probably need to rewrite the file just before you call fpassthru.

In other words, find a newer script that does what you want.

Well, you're opening the file in 'a' mode, which is "append writable only". I'm not sure what the stipulations on this file are -- can it be modified once it exists? Does it need to be appended to or should it be rewritten everytime. Regardless, I'm not sure, given the file pointer, that the order of things, vis a vis fpassthru() doesn't need to be different. It could be that you need to: open file fpassthru() write changes to file. It also may be that you need to write what you need to to the file, close it, and reopen it to pass the data back. Regardless of this, you need to open it in a mode different from 'a'

Depends on the payment processor(s) you are using. There's 2 levels of checking -- routines for checking the validity of numbers by the card, which are easy enough to find, and then the actual authorization checks, which require the payment processor. There's numerous PHP based shopping carts, and ecommerce systems around that you can look at for examples. For example: http://www.opencart.com/ which boasts to have support for over 20 payment gateways.

No worries, that is what this forum is for -- helping people who are actively trying to code php.

You could certainly do that and code around it, but you'd have to add that code to the component administration system. All that is happening is that the original system either sets (or doesn't) a url param named showtitloc. It then toggles the behavior on that. Take a look at your url's and see what it's doing -- probably it is setting showtitloc=1 when it was set for the title only. Your "Both code" could set it perhaps to showtitloc=2, when you want both displayed. Then you'd simply replace my code with a small switch statement where: 2: prints both (see my example) 1: prints the title only ($row->title) and otherwise returns htmlspecialchars( $row->venue, ENT_COMPAT, 'UTF-8' ) This should be easy enough for you to code, reading the php manual section on the switch statement, and looking at the code change I showed, vs the original. You'll have to delve into the component code to add the 3rd option.

This would make sense, because in many cases, the server would already be configured to send mail via whatever MTA exists on the server. Although spam filters can be a huge issue, when you're talking about low cost hosting, you typically can't expect to get the type of configuration you would have on a dedicated server or VPS where you run your own dns.

Not following you here -- unless you take measures to reconfig this, sessions are facilitated by a cookie. They don't go away until they expire and you can set a long expiration if you want. For something like form memory I don't think you need to go crazy, but yo can easily set them to expire in 7 days or whatever you want.

Virtual hug?

Yeah, but most of those are me telling people to rtfm. Its nice to see your committed gizmola, job well done. Thanks Thorpe, although Daniel is right in that next to you, I'm a piker. I also am not above firing off a thinly veiled RTFM.

You have a pretty obvious error with your temp variables. There's really no reason to make a temp variable called folderid, just so you can substr() it. Do it in one line. Again -- this assumes that you have added a folder column to the users table and it's the last column after the time. function addNewUser($username, $password, $email){ $time = time(); $folder = substr(md5(uniqid(rand())), 0, 10); /* If admin sign up, give admin user level */ if(strcasecmp($username, ADMIN_NAME) == 0){ $ulevel = ADMIN_LEVEL; }else{ $ulevel = USER_LEVEL; } $q = "INSERT INTO ".TBL_USERS." VALUES ('$username', '$password', '0', $ulevel, '$email', $time, $folder)"; return mysql_query($q, $this->connection); }