Search options (Page 4 of 7)

Ahh, i got the impression that he hosted it from his own hardware with a domainname from the hostultra thingie...

I think it'd be better to make some new files, alongside the current ones, and mod the output to fit into the small screen of handhelds etc.

Then you could choose to either visit the regular forum or the modded one with an examination of the http-request...

LHA rules *feels nostalgic*

Or you could do the following check when uploading:

<?
            $path = $DOCUMENT_ROOT . "/photo/";
            $image = getimagesize($_FILES['memberPhoto']['tmp_name']);
            if ($_FILES['memberPhoto']['size'] > 25600) {
                print("Photo to large. Max 25kb. Try again.");
            } elseif ($image[2] != 2) {
                print("Photo is not of an approved type. Only JPEG is allowed.");
            } elseif ($image[0] > 155) {
                print("Photo is to wide. Max width is 155 pixels.");
            } elseif ($image[1] > 155) {
                print("Photo is to high. Max height is 155 pixels.");
            } elseif (move_uploaded_file($_FILES['memberPhoto']['tmp_name'], $path . $o->memberID . ".jpg")) {
                print("Photo Uploaded...");
            } else {
                print("Upload Failed. Try Again or report error to webmaster.");
            }
            ?>

Or you could just play with imagecreate as well to automaticly resize the img by using getimagesize as reference: http://se2.php.net/manual/en/function.getimagesize.php

I think it's 5mb mail, but hey, try it...it's free...

That would not work on hosts similar to webhotels where you don't have your own server/config-persmissions.

One possibility when dumping would be to do backup in 2000 bit chunks with automatic naming like: backup_0-2000.sql, backup 2001-4000.sql or with a userdefined value if the host can take a higer value (the user could experiment on this)

An alternate would be to make the script dump the to a local dir within the admin-dir via the fputs (?) and just append to the file in 4k chunks.
Same with restore, to have an option to read a file in a local file-path with fopen and let it read in 4K chunks.

This way the sql-file can be accessed via ftp.

You're very welcome

i don't know, never tried them, but the offer hosting+mysql for free.
and i haven't heard of them until i stumbled on them which increases the likelyhood of them being reasonable stable and not over loaded yet

Ok.

I've got a hypothetical here:
I put the username, md5-hash password, ip, lastVerify in the cookie.

I put the sessionid, username, ip, lastVerify in a session.

On each page i check if the cookie-info corresponds to the session-info and if they match, then the user should be who they say they are, and if the session and cookie-info doesn't match up i force them to login (the cookie/session might be hijacked).
If the session & cookie match up, but the cookie is older then, say, 120sec's, verify the user against db to make sure all is ok (take sessionid & ip from the session, username, md5-password & ip from the cookie and all 4 must be present in the db to validate the user.

Stored in the db on the user-row is: username, sessionid, md5-pass, loginIP.

Of course i would make an option to bypass the ip-check if user is on dialup for instance with a field-value of 1/0 or similar.

I would like to not have a db-check on each page, but rather in a timed manner, mainly if the db is hosted off-site.

Wouldn't this be a viable option, or am i way off here?

Do you verify the user on each pageview in pun?
That is, do you query the db with userinfo?

I had an idea of putting some known variables, like email, remote_addr, username and some md5-hash in the cookie, and the same info in the session-vars and maybe use a loginTimeout of 60 or 120secs, and thus check if the timeout is older the X secs and do valitade, or if the cookie-info doesn't match those in the current session-vars do validate the user.

I'm looking to put the least stress on the db as possible, while maintaining a reasonably high security for the members, ie making sure that the persion is who it states.

EDIT: And i usually make md5's of info that does not -need- to be cleartext, like username for instance.

Thus a bunch of md5-hashes of the above variables in the cookie should be pretty safe?

Ahh, yes of course *missed that*

This way i can: $FIELDS[DBNAME] . $FIELDS[MEMBER_TALBE] . $FIELDS[DBNAME][MEMBER_TABLE]['session']
to build querys that will work with multiple db's, multiple tables and still not break the internat code structure if i wanted to make my script authenticate against say, pun, with pun's username/password fields if i wanted.

I think this approach is very underrated to make code portable because it looks complex when it's really not.

Anyways, now it's StarTreff-time...

try running htmlspecialchars(str_replace("<br>", "\n", $text)) or something?