Nabb

I don't get what you're trying to say - look at /include/session.php for example. Lots of cookies there.If you aren't going to have cookies, then the only options (which I can think of) are having to log in on every page, having some form of verification data (e.g. a session ID) on each link on each page, or storing the log-in data to be associated with your IP. I don't see how any of these are better than simply storing a cookie.

There's no reason to keep the user and password databases separate. One database should suffice, columns you would need are (feel free to change the names, e.g. password to psd, if you want): ID: Set this to auto-increment - Int with max length 4 should suffice, it allows for 10000 users, increase the length later if necessary User: A log-in username - Tinytext with max length 16 should be fine. Password: The hash of a password - Tinytext with max length 40. Sid: A session ID relating to a user - e.g. Tinytext with max length 40. Any other data you wish to keep can be stored as well, for example columns: LLI: The last logged in date Name: A user's first name etc. A hash function is a function which takes an input of any length, and returns a fixed-length output. Common hashes include MD5 and SHA1 (the latter is more secure). Hashes are used because they are irreversible (easily verified with the pigeon hole theorem). In a registration page, you should have a series of text boxes for each relevant column (i.e. username and password - plus extras you want like first name). On the page this data is submitted to, what you want to do it: Retrieve the data using $_POST['user'], where 'password' is replaced with whatever you named it in the previous page. You need some basic checks e.g. username is between 4 and 16 characters (long usernames are annoying!), username consists only of alphanumerical characters (or something similar). Calculate the hash of the password - e.g. $hash = sha1($_POST['password']); INSERT INTO the SQL database the relevant data. When you log in, (use a similar form to the registration form except only with username and password boxes), you should SELECT from the table WHERE the username and password (hash) match - if the mysql_num_rows($result) is 1 then success, else fail. You need to set a session ID associated with the account, which will be used to authenticate the user when he visits other pages. An example could be sha1($user+date("FjYg:ia"));. You need to UPDATE the session ID value stored in the database and set the value as a cookie to the client. When the user visits other pages, you should check whether the session ID is associated with any IDs in the database (basically logging in but checking for session ID match). I hope you realise how stupid this is, this less less secure than sending passwords as plaintext. If a hacker is able to sniff the password sent, they can easily log in, yes. If it's a hash instead, they can easily spoof the request (e.g. tamper data, javascript injection, packet editor). However if there is an SQL injection vulnerability, a hacker will immediately be able to access any account, regardless of password strength, if the hash is done locally. If the hash is done on the server, one would need to first crack the hash.

I haven't yet played around with local connections so I can't help you there (without reading off documentation and telling you things that you could easily find out yourself). Using GET is ridiculous, I did that for a while but since I was using a string of effectively random characters (to represent a level in my game), most symbols had to be escaped and thus the URL was now three times longer It's bad to put so much in GET - at one point I had too much data in there that the URL length was exceeded, and it was at that point I switched to using POST. Shared objects are fairly simple to use and should be able to solve your problems. The best tutorial is here (in my opinion) but I'll briefly describe it here: ShObj = SharedObject.getLocal("filename");ShObj.data.name = "Nab";ShObj.flush()(flush() saves the data to the file, if you don't call it then the data is only saved when you close the first swf!) Then in the other swf you can do something like ShObj = SharedObject.getLocal("filename");if(ShObj.data.name!=null){trace(ShObj.data.name);}else{trace("No data :(")}This isn't that good if both windows are going to be open unless you're going to either set an interval which continuously checks for changes, or force the user to click a button when he has updated in the other swf. I haven't come across using getURL() with POST data directly, and via documentation here, it seems that all variables are sent and that's pretty stupid. Another problem with this is each time you call getURL(), a new window will open. This may not seem like a problem, but if the system is for something like a level editor and corresponding testing area, and each time you hit 'test level' in the editor a new window came up for testing, it'd get pretty annoying. I managed to come up with something last time with javascript to get around this. Here's my method: (arg - when I made this last time I used double-quotes everywhere and thus had to escape all of them ) url = "<html><head><title>Redirecting...</title></head><body>Redirecting...<form name='aForm' method='POST' action='http://your.website.com/folder/file.php'><input type='hidden' name='stuff' value='" + escape (stuff) + "'></form><script language='JavaScript'>document.aForm.submit();</script></body></html>"; getURL ("java script:win = window.open('','Redirecting..',toolbar=0,status=0,scrollbar=0,resizable=0,width=550,height=550);win.document.open();win.document.write(unescape('" + escape (escape (url)) + "'));win.document.close()"); Using this, the same window will be used each time you press some button that opens the other one. And in file.php, you'd need something like: (I hear this is a bad way to do this - i.e. embed swf's) <?php$stuff = $_POST['stuff'];$heredoc = <<<LOLSTUFF<html><head><title>This is a title!</title></head><body bgcolor="#ffffff"><object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" width="550" height="550" id="file2" align="middle"><param name="allowScriptAccess" value="sameDomain" /><param name="movie" value="file2.swf" /><param name=FlashVars value="stuff=LOLSTUFF;$heredoc .= $stuff;$heredoc .= '><param name="quality" value="high" /><param name="bgcolor" value="#ffffff" /><embed src="file2.swf" FlashVars="stuff=';$heredoc .= $stuff;$heredoc .= ' quality="high" bgcolor="#ffffff" width="550" height="550" name="file2" align="middle" allowScriptAccess="sameDomain" type="application/x-shockwave-flash" pluginspage="http://http://www.adobe.com/special/errorpages/404.html; /></object>';echo $heredoc;?> Another way would be to directly echo all that stuff with document.write when you call getURL(), but that's really really ugly. Also, I probably escaped something too much, I tend to escape things a lot... edit) note: using FlashVars instead of using file2.swf?stuff=stuff saves bandwidth as far as I know - you'll need to load file2.swf again if you have ?stuff=morestuff a second time.

I tend not to click on ads unless the content advertised interests me. Or somehow the flash compels me (for example one of the Scion ads did this). Although sometimes I muck around on flash ads for fun - e.g. not shooting the gold iPod (which is pretty boring, because there's not many iPods to be shot), or getting one less than the required basketballs in the hoop.

How are you using the addItem function call? There are two ways to use it, the first is list.addItem("label","data"); The second is list.addItem({label:"label", data:"data"}); Both should work to all you to retrieve the data using list.selectedItem.data. There is another method to add a label to the list but as far as I know, it doesn't allow you to store data with it. (list.label.push("label"), but list.data.push("data") fails) Note that you can store data in an array elsewhere if desired and push to it seperately to calling addItem (or define a function which does both ), and retrieve the data from the array by using array[list.selectedIndex].. ...okay I see you've fixed your error (saw the update when using preview post), but I'll leave this post here to inform anyone who might later need this!

Like many others, I like the new myCENT system. It allows for customization in plans, and also allows the 'free webhosting' to branch out further as it is also possible, with the new system, to obtain something like a free VPS, or a free domain. Compared to the previous system, the 'flaw' in which you would lose credits when you apply for hosting is fixed (wouldn't it be horrible to lose all your dollars when you bought a plan). This allows for one to save up the earned CENTs (and dollars ) which makes purchases of other items feasible (250 credits on the old system? bleurg!)There is also a feeling that we are being rewarded with money instead of hosting, except the money can only be used on the Xisto - Support website (so it's like a gift-card basically), but that's probably because that's how we're being rewarded

Yes, that is the benefits of the CENTs system - it allows you to go beyond the plans offered by the previous system. Although what you should say is that any package can be redeemed as long as there have been enough myCENTs transferred, having lots of CENTs in your Xisto account doesn't do anything until it's transferred across to the billing page.

That newbie tag looks really weird on you, hurry up and get rid of it

Hmm... The Nabb Group: Nabb (Nabb) It seems the Nabb Group is invading the Coding Group's thread

That's insane, and it has the potential to become a huge problem to people all around the world.. like a HUGE security threat.. A few things - this won't work well when there are many people around, unless it's possible to distinguish between different laptops easily (in which case you have people on the same laptop model ) Wouldn't the EMR created be extremely small and thus any nearby electronic devices would be able to interfere.. A mouse controlled interface could easily thwart this - for example the system MapleStory uses:

What's the point of showing everyone's current myCENT value to the public? You can't really use it for bragging rights as it resets after 100.. If it's for knowing when you'll get CENTs transferred, shouldn't it simply replace (or be put next to) the hosting credits label on the index page?

Do you have the licenses for you to be able to put Photoshop on the computers? I wouldn't think so as it's quite pricey... It would only be installed on some computers because your school only purchased that many licenses. If you want Photoshop on more computers, purchase more licenses for your school..

Wait so CENTs and credits are completely separate - credits are used to remain hosted and the real money is used for real purchases and not deducted daily?Doesn't that mean you can buy Xisto credits with the CENTs to effectively double the credits you make per post? Also, does this new system mean we can purchase domains without having to store up 250 credits?I'm so questioning today

I would assume so, read this part: I nearly entered a different email, gmail lets me arbitrarily add and remove periods, which I tend to do.. o_o

WHOO This is so awesome. As is all the other new features! Hail OpaQue!

I think that's a problem of scope (it's a killer when you're starting flash if you don't have programming experience). Changing it to _root.gotoAndPlay should suffice. If you leave the _root out, I think it would try to make the button go to frame 'scene1'.

ctrl-u(a fancy way - bookmark this (unless you're in IE)) java script:window.location="view-source:"+document.URL

I don't know C++ specifically, but I'd assume that: str returns the ith position in the string of str str returns undefined for anything after 'This Is A Test' undefined evaluates to false (i.e. breaks the loop), while any character (e.g. "i", "A") evaluates to true.

Some on that effect here Basically you just use setInterval to call a function every now and then. In more depth -> Have a function which is called by setInterval: ->Lowers the alpha ->Clear the interval is the alpha is low enough Have another function that increases the alpha instead When you roll over, call setInterval for decreasing alpha, clear interval for increasing alpha When you roll out, clear the interval for decreasing alpha and set interval for increasing alpha Code (I have the object named 'ob', ideally you would use this._alpha except I couldn't get it working and I've got to go now..) onClipEvent (load) { function DecreaseAlpha () { _root.ob._alpha -= 2; if (_root.ob._alpha <= 50) { clearInterval (DecreaseAlphaInterval); } } function IncreaseAlpha () { _root.ob._alpha += 2; if (_root.ob._alpha >= 100) { clearInterval (IncreaseAlphaInterval); } }}on (rollOver) { DecreaseAlphaInterval = setInterval (DecreaseAlpha, 40); clearInterval (IncreaseAlphaInterval);}on (rollOut) { IncreaseAlphaInterval = setInterval (IncreaseAlpha, 40); clearInterval (DecreaseAlphaInterval);}

I'm pretty sure that $rows is an array, hence the name 'mysql_fetch_array'. You'd want to retrieve from the array the value referenced by the pointer 'inc' (name of your incremental column)... heh, I hope it sounds like I know what I'm takling about $rows['inc']Replace 'inc' with whatever your incremental column is called and you're set to go

Teehee. Maths isn't really memorising formulas - it's more about understanding what you're doing.. no point knowing x=(-b?√(b?-4ac))/2a if you can't actually apply it! Going over a course outline and seeing what you know and don't know would be a good way to see what you need to learn, but you can also do a few past papers and see what you did wrong and learn from those mistakes...

It's a hash. Not an encryption. Hashes are irreversible, encryptions can be decrypted. Hashes have a fixed length output, encryptions have an output length proportional to the input length (generally) The fact that hashes have a fixed length output should make it quite obvious that they are irreversible. There are over 2^160 possible string inputs, while only 2^160 possible string outputs. This means via the pigeon hole principle that there will be outputs with multiple possible inputs. Which means that it's impossible find the input used to create the hash (while technically possible to find an input with the same output.). Here's a basic type of hash that can't be reversed: Input: A string Output: The first letter of the string There is no way you can determine the input given the output (unless you're told it's one character long ). Of course if this were a hash used for securing a website, it wouldn't be hard to find an input which gives the same output! Hashes generally try and have collisions (i.e. two inputs giving the same output) hard to create, and as of current SHA-1 has had no collisions found (while distributed computing is continually trying to find some!) but MD5 has had collisions (view here). Using sha-1 should be enough for storing passwords in a website. If someone can somehow retrieve these values (e.g. by means of SQL injection) then your passwords are safe as long as they are of decent length (e.g. at least 8 or 9 characters) and not dictionary words (but something like 'messenger6' isn't a very secure password either!) - ideally a random combination of alphanumeric+symbols. A common method of protection is to use a salt on hashes. This can be changing sha1($_POST["pass"]) to sha1($_POST["pass"]."This is a salt! It's very long to hinder brute-force attempts!").

Wouldn't new posts just store more data to certain tables (and possibly add more tables)? It wouldn't really be a good idea to make one SQL database per post. If you're talking about SQL database space, then you get up to 500MB (shared with hosting space) if you go for the 30 credit plan. You should be able to use as much CPU as you need as long as it has no effect on others. Which would require a lot of visitors (..or doing lots of CPU intensive tasks like backups... don't do too many of those!)

Alternatively, stop downloading porn video 'codec's, usually the source of viruses. avi extensions are pretty harmless. A common trick is to name a file something like 'cute.jpg.vbs', and people with known extensions disabled will see it as 'cute.jpg' and open it. That's pretty stupid as you should realise that .jpg would be removed and look for the actual extension.. the easiest way is to have Windows set to display all extensions. Adware often has these types of ads. Are people really gullible enough to believe these AVs help? I've had to do this before when Avira didn't pick up the virus! Useful information.It probably helps to have TeaTimer running (part of Spybot S&D, it monitors important parts of the registry and allows you to deny changes).

Maybe the credits should be dropped when creating the application (no daily credit loss yet though)? This way you can earn credits between posting and getting approved/denied? I know it doesn't solve the problem of losing credits, but you can lose _less_... Also it slaps anyone spamming and trying to apply in the face (consider the ambiguity ), because they lose the 30 or more credits ;p