Web Development Questions That Don't Need Their Own Thread v2
3,079 replies, posted
[code] $('form#upload').submit(function() {
$('input[type=file]').each(function(e) {
var ID = $(this).attr('id');
if(ID == "error") {
var Error = true;
}
});
if(Error == true) {
return false;
alert('Error!');
}
});[/code]
I have three file inputs, each is validated when the field changes. For e.g. if the field is empty it'll add a ID of "error" - that works fine etc.
However the code I pasted above doesn't work as it should. It doesn't allow me to access the variable "Error" outside the each function.
[QUOTE=kragmars102;33385330][code] $('form#upload').submit(function() {
$('input[type=file]').each(function(e) {
var ID = $(this).attr('id');
if(ID == "error") {
var Error = true;
}
});
if(Error == true) {
return false;
alert('Error!');
}
});[/code]
I have three file inputs, each is validated when the field changes. For e.g. if the field is empty it'll add a ID of "error" - that works fine etc.
However the code I pasted above doesn't work as it should. It doesn't allow me to access the variable "Error" outside the each function.[/QUOTE]
I believe the reason is that you're specifying the Error variable within the each function, try replacing it with this:
[code]
var Error = ''
$('form#upload').submit(function() {
$('input[type=file]').each(function(e) {
var ID = $(this).attr('id');
if(ID == "error") {
Error = true;
}
});
if(Error == true) {
return false;
alert('Error!');
}
});
[/code]
Still doesn't seem to work.
[QUOTE=kragmars102;33385595]Still doesn't seem to work.[/QUOTE]
The reason while the Error! alert isn't working is because you are returning false before it has alerted, try this:
[code]
var Error = ''
$('form#upload').submit(function() {
$('input[type=file]').each(function(e) {
var ID = $(this).attr('id');
if(ID == "error") {
Error = true;
}
});
if(Error == true) {
alert('Error!');
return false;
}
});
[/code]
Thanks guys I fixed it, really simple mistake. The id attr actually had a space in it by accedint. " error" instead of "error"
[QUOTE=Wudozet;33382265]You need to change how you refer to each element (a#events, a#events:hover, etc) to be the same as how you referred it when setting the background (#navMenu li a). So just change each to #navMenu li a#id and #navMenu li a#id:hover. Not entirely sure why this has to be done, but it should make for more readable css anyway.
Another way would be to put !important after the css rules changing the background-position, but I don't think that would be the best way to go about it.[/QUOTE]
Thanks that worked.
[QUOTE=jmazouri;33379098]That seems to cause the entire page to freeze when the function is run :c[/QUOTE]
Well you need to check the javascript console and fix whatever is erroring.
A question for the site I'm developing: How does the server generally, well, handle users in forums and such?
What I have in mind is a system where every page is a response function. Certain functions (Reply boxes, a link to your profile, etc.) are only shown to users. Every time the server gets a request or query or whatever, it checks the cookies of whomever is browsing, checks his identity, and displays the site content accordingly. Does it work anything like that or should I use another approach?
[QUOTE=jaybuz;33386664]Well you need to check the javascript console and fix whatever is erroring.[/QUOTE]
That's the issue - Nothing is erroring. The page just freezes.
[QUOTE=Eudoxia;33387746]A question for the site I'm developing: How does the server generally, well, handle users in forums and such?
What I have in mind is a system where every page is a response function. Certain functions (Reply boxes, a link to your profile, etc.) are only shown to users. Every time the server gets a request or query or whatever, it checks the cookies of whomever is browsing, checks his identity, and displays the site content accordingly. Does it work anything like that or should I use another approach?[/QUOTE]
This sounds like MVC, read about CodeIgniter or any of the many other MVC frameworks (Model View Controller)
[QUOTE=Eudoxia;33387746]A question for the site I'm developing: How does the server generally, well, handle users in forums and such?
What I have in mind is a system where every page is a response function. Certain functions (Reply boxes, a link to your profile, etc.) are only shown to users. Every time the server gets a request or query or whatever, it checks the cookies of whomever is browsing, checks his identity, and displays the site content accordingly. Does it work anything like that or should I use another approach?[/QUOTE]
Yup, that's pretty much how it works.
[code]$src = random_string().".".$extension;
setcookie("recent",'"'.$src.'"',(time()+3600*24), "/" ); [/code]
[code]Warning: Cannot modify header information - headers already sent by (output started at /home/beztdesi/public_html/i/index.php:4) in /home/beztdesi/public_html/i/index.php on line 73[/code]
I've had this issue before with PHP's header function, however I've never had this problem with cookies before.
I've tried using ob_start(); - however it didn't work.
do you have a stray space, tab or newline before your opening <?php tag?
I've thought about that as well, but no I don't.
edit:
Fixed it, thanks. I moved the PHP before the <html> tag. Seemed to fix it.
[QUOTE=Octave;33392292]do you have a stray space, tab or newline before your opening <?php tag?[/QUOTE]
does this actually change it's behaviour?
[QUOTE=RusselG;33392331]does this actually change it's behaviour?[/QUOTE]
It sends that character to the browser and so if you tried to send headers after it it'd generate that error.
[QUOTE=RusselG;33392331]does this actually change it's behaviour?[/QUOTE]
It may, if the stray space/character is sent to output and then you attempt to, for example, send headers. That's also why the Zend guidelines recommend the omission of the closing php tag when applicable (class files, for example).
Oddly enough it does, PHP is extremely sensitive.
[QUOTE=kragmars102;33392516]Oddly enough it does, PHP is extremely sensitive.[/QUOTE]
Not at all related to PHP, it's just how HTTP works (the spec defines that headers go in the top, and the body in the bottom of the message). You can abstract away the underlying implementation to bypass this, by for example capturing all the output and making sure it's sent in the right order to the client - this is a standard feature of many frameworks.
[QUOTE=Octave;33389307]This sounds like MVC, read about CodeIgniter or any of the many other MVC frameworks (Model View Controller)[/QUOTE]
Thank you, I should mention: I'm writing all of this from scratch using AllegroServe as the server and all I have is Common Lisp and patience, so no PHP allowed. Not that I have anything against PHP, it's just that I'd rather learn how to use Lisp for web programming and share that with other people because it's a language that seriously needs some tutorials.
[QUOTE=mobrockers2]Yup, that's pretty much how it works.[/QUOTE]
Well, I guess it should do then.
[QUOTE=Eudoxia;33393438]Thank you, I should mention: I'm writing all of this from scratch using AllegroServe as the server and all I have is Common Lisp and patience, so no PHP allowed. Not that I have anything against PHP, it's just that I'd rather learn how to use Lisp for web programming and share that with other people because it's a language that seriously needs some tutorials.
I think you should use sessions instead of cookies tho.
Well, I guess it should do then.[/QUOTE]
I'm reading into it, but don't sessions die when the user closes the browser?
Another question, re security. How should I handle the authentication of the user? (Using cookies)
I thought something like this could do: When the person registers, use an algorithm (One that always outputs the same results, not one that uses an ever-changing seed) to encrypt the password and store it as an in-memory representation and also in the server's hard drive.
When a user logs in, the password he entered is instantly encrypted and compared to the encrypted password in his file. If they match then the user logs in. The cookie that is stored in the person's computer contains the username and the (Encrypted) password, which is sent to the server and compared directly to the static version that is stored, without encrypting again. If someone found the file describing the algorithm the passwords could probably be cracked by working backwards from the encrypted version in someone's stolen cookie, but there would be no pre-made tool to decrypt it since only encryption is required.
The alternative is to keep the plain-text password in the cookie and encrypt it and then compare it to the encrypted version on the servers, but then passwords could be cracked by stealing cookies through XSS and what not.
[QUOTE=Eudoxia;33394106]I'm reading into it, but don't sessions die when the user closes the browser?
Another question, re security. How should I handle the authentication of the user? (Using cookies)
I thought something like this could do: When the person registers, use an algorithm (One that always outputs the same results, not one that uses an ever-changing seed) to encrypt the password and store it as an in-memory representation and also in the server's hard drive.
When a user logs in, the password he entered is instantly encrypted and compared to the encrypted password in his file. If they match then the user logs in. The cookie that is stored in the person's computer contains the username and the (Encrypted) password, which is sent to the server and compared directly to the static version that is stored, without encrypting again. If someone found the file describing the algorithm the passwords could probably be cracked by working backwards from the encrypted version in someone's stolen cookie, but there would be no pre-made tool to decrypt it since only encryption is required.
The alternative is to keep the plain-text password in the cookie and encrypt it and then compare it to the encrypted version on the servers, but then passwords could be cracked by stealing cookies through XSS and what not.[/QUOTE]
[url]http://php.net/manual/en/book.hash.php[/url]
[editline]22nd November 2011[/editline]
mainly
[url]http://www.php.net/manual/en/function.hash.php[/url]
or
[url]http://www.php.net/manual/en/function.hash-hmac.php[/url]
[editline]22nd November 2011[/editline]
also i made a good post about sessions and cookies a while back
[editline]22nd November 2011[/editline]
here it is
[url]http://www.facepunch.com/threads/1092866?p=30621854#post30621854[/url]
If I understand it right, a session is maintained with a cookie by passing an ID. Is it really all that different from identifying a user with a username-password key-value pair in the cookie data? Would it be a significant slowdown?
(CL was not really intended as a web programming framework and doesn't use sessions, and I'd rather not implement a whole PHP-equivalent framework)
My biggest concern would be the security of storing user authentication in a cookie.
Well you should never store a plaintext password in a cookie. There are multiple ways to do it, one of my favorites is declaring (And storing) a random string during login and using that as the user identifier for a cookie.
That sounds much better, thanks.
Could anyone point me in a direction where I could earn money with webdesign? I don't really want to work with any clients yet, so maybe some sites where I could sell templates or stuff? I know of dreamtemplate and themeforest, but I highly doubt they'd accept mine.
[QUOTE=Torekk;33397400]Could anyone point me in a direction where I could earn money with webdesign? I don't really want to work with any clients yet, so maybe some sites where I could sell templates or stuff? I know of dreamtemplate and themeforest, but I highly doubt they'd accept mine.[/QUOTE]That should tell you something, get better at designing
So, the user logs in, his password checks out, and until he logs in a cookie persists containing an ID that was generated exclusively for the user, a small integer that's cheap to store and fast to compare, and tells the server whose HTML it should display.
Is this how a session works, essentially?
Sounds about right, but it would be a hash instead of an integer.
Edit: And the hash should expire after a certain period of time.
Sorry, you need to Log In to post a reply to this thread.