Re: [PHP] POST form File Upload Progress Bar?

[CompMan86]

Hi, Thanks for your response =) I don't know much about javascript, so if
you could show me an example that would be great.

Weston Houghton [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...


 My cheap trick around this is to have an onClick event on the form submit
 button that brings up a small window with a progress note in it, and an
 animated gif of a prgress bar.

 As the page does not unLoad until the upload is finished, I use the unLoad
 event of the body tag to close that progress window.

 Generally works really well for me. I can show you an example if you like.

 Wes



  I have a POST form with a file upload field. Users will be uploading
  pictures. What would be the most professional way to tell them their
  file is
  uploading and to please wait? Since the action page won't execute until
  after the image is done uploading, is there a way to have an
  intermediary
  page load telling them to please wait, and that page will take the image
  and
  upload it? Or should I just put a note in the upload form warning them
  about
  the long upload times and gray out the submit button with javascript
  after
  it's clicked?
 




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] How to keep form inputs from being cleared

[CompMan86]

I posted about this a few days ago. I received several responses but
none of them were very helpful (thanks for the effort though). I finally
figured out what it was by process of elimination. At the top of my
registration form, I put session_start() just like I did for all my
other scripts. Well it turns out that by doing this, for some reason, it
clears the form. I have a hunch that the cookie request by
session_start() has something to do with it. Well, the only reason
someone would be at the registration form would be if he/she was not a
member, therefore the session ID would be pointless.
 
This is the major flaw of PHP's built in sessions imho: If a user
disables cookies, the session functions assign the session ID to the
constant SID. However, if the SID is not passed on religiously, a new
session will be made. In an instance like this where session_start()
cannot be used, you can't pass on the SID. It seems like I'm just going
to resort to requiring that my users enable session cookies. The hastle
of making the code to use both SID and/or cookies just doesn't seem
worth it. If anyone has any ideas of a resolution to this problem, feel
free to post here or email me.

Re: [PHP] Need opinion On sessions - Cookies mandatory?

[CompMan86]

If there are two people behind a NAT, then the site would check for a
session ID and the IP. If a session ID is introduced AND their IP
matches the session, they are allowed to proceed. This would prevent
people from moving a session ID to another machine. If two people are
behind a NAT and share a session ID, I don't think there is a way of
preventing them to be assumed as the same person. So basically, it will
try to use cookies alongside a matching IP, and if cookies are disabled,
it will use the GET method alongside a matching IP. It just makes a
double check of the user...half the risk of transferring session ID's
among people...but still not fullproof...but I don't think there is a
fullproof way.

Dl Neil [EMAIL PROTECTED] wrote in message
news:0ad801c1a4ba$3d49bec0$7215100a@jrbrown...
 Entering the conversation late...
 
 1 IP addresses
 Remember these are not necessarily 'unique'. If two of us here log in,

 won't we appear (to you) have the same IP address if we're 'hiding' 
 behind a NAT (Network Address Translation) box? Also dial-up users 
 share a pool of IP addresses which are reallocated between customers 
 as they disconnect/reconnect.
 
 2 Cookies
 I think someone has already made points against their use. Many 
 corporates set up/require that browsers are configured to reject all 
 cookies (plays havoc with many shopping and banking sites). Obviously 
 there is popular advice that cookies are 'not good', because I've had 
 a number of friends and clients tell me that they regularly clear out 
 their 'cookie jar' - and need help when they get over enthusiastic and

 clear more than they should...
 
 There's a balance between easing life for those who are 'in', and 
 turning off those trying to arrive. The trick is finding it! =dn
 
 
 - Original Message -
 From: SpamSucks86 [EMAIL PROTECTED]
 To: 'PHP-General' [EMAIL PROTECTED]
 Sent: 23 January 2002 23:46
 Subject: RE: [PHP] Need opinion On sessions - Cookies mandatory?
 
 
  The idea of building a website is largely to accommodate as large a 
  portion of your visitors as possible. I'm not worried about people 
  bookmarking sessionID's, but what if someone copy/pastes the URL to 
  a friend and they use the section. My friend gave me an excellent 
  idea, and that is to check their IP and store the IP in the session.

  If the IP doesn't match, then start a new session. This would be 
  perfect, because there's a double check. If someone disconnects to 
  the internet but never closes their browser, I don't think they 
  should be allowed to continue their session anyway, they should be 
  required to login again.
 
  -Original Message-
  From: Nick Wilson [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, January 23, 2002 3:35 AM
  To: [EMAIL PROTECTED]
  Subject: Re: [PHP] Need opinion On sessions - Cookies mandatory?
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
 
  * and then Jason G. blurted
   If cookies do not work, then you must have a session_id appended 
   to
  the
   URL.  HTTP is a stateless protocol.  So every time you make a
  request via
   HTTP, you must let PHP know what the session_id is either through
  cookies,
   or url query strings (or possibly posted with a form).
 
  Yep, now I'm with you. The amount of times you'd see that kind of 
  ugly URL would be fairly minimal in most situations as most users 
  these days aren't even aware they *can* disable cookies.
 
 
disable cookies, but appending the session ID could be a 
security
  risk.
Consider this: Someone is viewing a page and says oh cool, I 
want
  Joe
to see this. He then copy/pastes the URL, sessionID and all, 
to
  Joe,
who then loads up the page using his friend's SessionID. With
  cookies,
this would not happen.
   
   Not a problem. The session is *destroyed* as soon as a user 
   closes
  the
   browser.
  
   A session will only be *destroyed* if it uses a cookie. PHP never
  knows
   when you close the browser, but the browser will remove the 
   cookie.
  Next
   time you fire up the browser, it will not send the cookie, and a
  different
   session will be started.
 
  Sure. But there is some kind of clean on the host machine right? You

  couldn't expect to continue a session a week later because you've 
  bookmarked a URL containind a SID. I think this is controlled by 
  something like a timeout var in the php.ini.
 
   In my personal experience, using cookies only has not proven to be

   a problem.  Your call.
 
  When you say using cookies only do you mean 'requiring' the user to 
  have cookies enabled?
 
  - --
 
  Nick Wilson
 
  Tel: +45 3325 0688
  Fax: +45 3325 0677
  Web: www.explodingnet.com
 
 
 
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.0.6 (GNU/Linux)
 
  iD8DBQE8TnW3HpvrrTa6L5oRAthOAJ0WOpUWC5fFMokhYF2QsaQaQolp+wCfQWHL
  03BrqRN2kLf+VWC/tzDSHho=
  =Gek0
  -END PGP SIGNATURE-
 
 
  --
  PHP General Mailing List (http://www.php.net/)
  To unsubscribe,