rejetto forum

Flash Uploader

TSG · 60 · 61225

0 Members and 1 Guest are viewing this topic.

Offline Foggy

  • Tireless poster
  • ****
    • Posts: 806
    • View Profile
mmm, and are you able to pass user/pass as POST data?

I do believe that sending the user/pass as post data is possible, you can craft your own POST requests in flash.

Though I am unsure if you can add the user/pass as a POST variable when uploading a file via flash. I would think you can though.

Check out the "fileReference" class in flash to see how the uploading will work.


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13523
    • View Profile
it's technically possible.
i was just wondering if the lib/tool you use to do the upload was designed to let you do it.
swfupload does as far as i can recall.


Offline Flynsarmy

  • Occasional poster
  • *
    • Posts: 92
  • DENIED!
    • View Profile
    • Flynsarmy
I've been reading through this thread and have come up with a couple of ideas.

Firstly: How would you get the user/password TO flash without having it visible in the code? When you log in,
you enter your username and password into the form and hit submit - HFS logs you in. But then how would your
flash applet receive these login details without you either entering them again into the flash applet or visibly
sending the info to the applet in the code as it is loaded? That wouldnt' be a MAJOR security risk because you
already know your own user/password but it's still pretty dodgy in my opinion...

Anyway the idea I came up with that's kind of a compromise is to have a flash applet that does nothing more than
pop up a browse box. Our main problem (besides not having some fancy progress bars on upload) is that we can't
select multiple files at once. So i'm wondering if its possible to activate the applet as you click a browse button
which then pops up a browse box. You select your files and hit ok and flash then uses its externalinterface call or
whatever it is to send the file info back to javascript which in turn dynamically creates its file input boxes and
submits them with AJAX or whatever you want to do with them.

This would give the appearance of a complete HTML solution which allows multiple files to be selected instead of
just the one.


Offline TSG

  • Moderator
  • Tireless poster
  • *****
    • Posts: 1935
    • View Profile
    • RAWR-Designs
I like your solution and it might actually be very possible, however the word 'compromise' is very true there. I believe flash handles uploading better than a browser, and real upload progress would be really nice. Maybe with an ahah/ajax solution (how does gmail do its dynamic progress?) we can get real progress but I would prefer just to use a nice flash applet for a simple uploading solution that anyone can implement. It really is a shame that its not that simple.


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13523
    • View Profile
sorry for the late reply

Firstly: How would you get the user/password TO flash without having it visible in the code?

no way with current system.

Quote
Anyway the idea I came up with that's kind of a compromise is to have a flash applet that does nothing more than
pop up a browse box.

that's what swfupload does. the rest is html+js.


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13523
    • View Profile
Maybe with an ahah/ajax solution (how does gmail do its dynamic progress?)

i had a quick look, and i can tell you that the bar is not flash, tho gmail requires flash for that (they say it in the settings page)


Offline nuvolablu

  • Occasional poster
  • *
    • Posts: 61
    • View Profile
hi guys,
   I think this is the major urgent feature requested!!
Please work on it...
I hope to see it working soon.
Best regards.
S.



Offline TSG

  • Moderator
  • Tireless poster
  • *****
    • Posts: 1935
    • View Profile
    • RAWR-Designs
All of us agree nuvolablu, but until someone figures out how to get Flash's connection to work with HFS on a protected folder, it will not be possible.

This is the major thing holding up our template updates, we intended this to be the next big update to top off 2009, but obviously not. It has worked out ok cause we are both very busy, but all the same, we want this feature too.


Offline teslaman

  • Occasional poster
  • *
    • Posts: 19
    • View Profile
(Revives thread) First off, thanks rejetto and TSG for sharing the swfupload info/how-to. Since I don't use a protected upload folder it has being working great for me! :)

Now for the bummer. Since one of the more recent Flash 10 updates, the uploader always comes back with a Http 301 error for me and everyone else that has tried...across multiple browsers. :'( This happened in early August, so v10.1.53.64 should have been the last Flash release that didn't give the 301 error. The upload still finishes fine, but I ended up disabling the "re-queue on error" feature since it would just keep looping the upload.

I had thought this was strictly a swfupload problem since their latest version pre-dates the Flash 10 update, but now I'm not sure. I decided to try past betas and the latest stable of HFS. After trying over 20 builds I found that the latest stable and the betas up to build #171 all give a successful upload message...after about 2 minutes of waiting past 100% file upload that is. It used to be instant, but I was testing on localhost this time and before, doing it that way just crashed my connection. :o Perhaps the latest Flash version has slowed it down?....who knows, haha. Sadly, all the beta builds that I tried after #171 give me the 301 error in the Flash uploader. :(

Having found that out, I thought I would mention it in case there is possibly a yet unseen bug in HFS that would cause this error with flash based uploading in the future? If you want to check it out, I've attached my customized code of the swfuploader. I've also tried the original code in case I had messed something up, but it still gave the 301 error. :(

Just FYI, Here's all the builds I tried that caused the uploader to throw the 301: #173, 174, 175, 176, 177, 178, 179, 200, 230, 240, 254, 257, 258, 259, 261, 262, 263, 264, 265 and 272. Oh and I did the testing with all reset settings and template, just to be sure.  ;)

Also, at the very least...If anyone knows some code to throw in to make it ignore the 301 error, that would be great!  ;D

Here's SWFUpload's debug log of the issue....doesn't help me any, haha.
Code: [Select]
SWF DEBUG: Event: fileDialogStart : Browsing files. Multi Select. Allowed file types: *.*
SWF DEBUG: Select Handler: Received the files selected from the dialog. Processing the file list...
SWF DEBUG: Event: fileQueued : File ID: SWFUpload_0_0
SWF DEBUG: Event: fileDialogComplete : Finished processing selected files. Files selected: 1. Files Queued: 1
SWF DEBUG: StartUpload: First file in queue
SWF DEBUG: Event: uploadStart : File ID: SWFUpload_0_0
SWF DEBUG: ReturnUploadStart(): File accepted by startUpload event and readied for upload.  Starting upload to /Upload for File ID: SWFUpload_0_0
SWF DEBUG: Event: uploadProgress (OPEN): File ID: SWFUpload_0_0
SWF DEBUG: Event: uploadProgress: File ID: SWFUpload_0_0. Bytes: 27200. Total: 27200
SWF DEBUG: Event: uploadError: HTTP ERROR : File ID: SWFUpload_0_0. HTTP Status: 301.
SWF DEBUG: Event: uploadComplete : Upload cycle complete.
Error Code: HTTP Error, File name: 123.jpg, Message: 301
« Last Edit: December 22, 2010, 10:34:20 AM by teslaman »


Offline SilentPliz

  • Operator
  • Tireless poster
  • *****
    • Posts: 1298
  • ....... chut ! shh!
    • View Profile
Hi Teslaman! :)

I also made some tests with SWFUpload, and I got a bit the same results / conclusions as you.

I think as long as rejetto have not finished the development of the "Support the session based login" (Perhaps in build 273)
the error message "301" will be inevitable ... unless you find a HFS script that will get around the problem.

For now, I choosed to ignore the error messages, and display only messages of success (it's good for cheerfulness :) )

I seeing also that Flash Player 10 crash quite often in many applications.

There is also a known bug in flash player with cookies ... it takes into account primarily the cookies of Internet Explorer, even if IE isn't the browser used to upload. ???
There is many informations about this bug, and some ways to work around are available online. (search with google: flash bug cookies)
I am not yet able to make a viable script to work around this bug.

There is also a disturbing restriction for users of SSL (https) ... Adobe Player seems does not accept self-signed certificates (it work fine with "certified certificates"). :-\

The concerns of unreliability of flash suggest that it might be better to move towards solutions only Ajax / Java based for HFS
 ... drag and drop is possible in more with some of these solutions.

I'll post the latest status of my essays, you can try ... with any luck it satisfies you.

The main difference with your solution is that with mine you can upload in any folder with the rights to "anyone"

You can also send files to a sub-folder restricted for "anyone" and located in a folder "restricted for user account".
This workaround allows to limit the "upload rights" for some user accounts.

Tell me if it works better for you.


I advise you to use for your tests the beta build 271:

http://www.rejetto.com/forum/index.php/topic,9184.msg1052472.html#msg1052472

- You put the folder named SWFUpload in the folder of hfs.exe
- You load in HFS the template included in the .zip: default.tpl

... everything is ready for operation.  ;)


Edit: Version included is the last beta of SWFUpload... use it with Adobe Flash Player version 9.028 and above.
« Last Edit: December 22, 2010, 06:52:05 PM by SilentPliz »


Offline teslaman

  • Occasional poster
  • *
    • Posts: 19
    • View Profile
Thanks SilentPliz! Yep that worked. :) Unfortunately, in my setup I need to keep the other error codes intact for the users since they can't see the actual file after they upload it....short of manually typing the filename in the address bar. And thanks for the information allowing uploads to multiple folders and sub-folders. 8) I currently only use a single upload folder for everyone, but that code will come in handy if I ever need to add more! :)

As a workaround, I'm sure there is an easy way for experienced coders to exclude just the 301 errors, but sadly I am no good at writing such code. For now I just have a note on my upload page that says to just ignore the 301 error, haha. ;D

Yeah, since the 301 error only appears after the #171 build, hopefully it is just a minor bug in HFS. :) Before testing different builds, I had been hoping it was just a new bug in the Flash 10 update, but after several updates between August and now, the 301 error remained. :(

Yeah I have never been that fond of Flash. It seems more often than not that it just slows things down and causes problems, especially after Flash updates. :-X

Did you notice any improvements with the latest beta of SWFUpload? Since it also gave me the 301 error, I had previously decided to keep the older one since it still worked otherwise and was 170kb smaller in size. :o

Cheers!


Offline SilentPliz

  • Operator
  • Tireless poster
  • *****
    • Posts: 1298
  • ....... chut ! shh!
    • View Profile
... Unfortunately, in my setup I need to keep the other error codes intact for the users since they can't see the actual file after they upload it....
 And thanks for the information allowing uploads to multiple folders and sub-folders. Cool I currently only use a single upload folder for everyone, but that code will come in handy if I ever need to add more!

Replace
upload_error_handler : uploadSuccess,
by
upload_error_handler : uploadError,

You will see reappear the error messages ... including the 301. :-\
------------------------------------------------------------------

With my version included in a template (*.tpl), the page is refreshed after uploads, so users can see what has been uploaded ... unless you decide otherwise in the parameters of HFS.

upload_url: "{.cut||-1|%folder%.}", will not work if you use this code in a page in html (*.htm,*.html)
This macro will works only in a template file (*.tpl) or in a "diff template".

Did you notice any improvements with the latest beta of SWFUpload? Since it also gave me the 301 error, I had previously decided to keep the older one since it still worked otherwise and was 170kb smaller in size.

SWFUpload is evolving along with Adobe Flash Player.
Some SWFUpload commands become obsolete from one version to another.
I think it is useful to keep SWFUpload updated to comply with changes in the Flash Player ... and to avoid other problems in addition of the error message 301. ;D

My version is compatible with Flash Player 9.028 to 10.xxx
....
         var settings = {
            flash_url : "/SWFUpload/js/swfupload.swf",
            flash9_url : "/SWFUpload/js/swfupload_fp9.swf",
....
« Last Edit: December 23, 2010, 06:45:47 PM by SilentPliz »


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13523
    • View Profile
After trying over 20 builds I found that the latest stable and the betas up to build #171 all give a successful upload message...

thank you for your effort.
This is a very useful information indeed.
In build next to #171 (#173) the code for upload was heavily changed for supporting forms.
I guess that's where the problem have been introduced.
If you untick the "only served requests" in the log options, you should get a "Not served: 301 - Moved" in your HFS log. Do you?


Offline SilentPliz

  • Operator
  • Tireless poster
  • *****
    • Posts: 1298
  • ....... chut ! shh!
    • View Profile
If you untick the "only served requests" in the log options, you should get a "Not served: 301 - Moved" in your HFS log. Do you?

That's right.
Uploads are still performed correctly.
And %user% does not appear in the log.

Event [+upload success] is often not executed.