submitting multi-part data (file attachments) after a login
10 views
Skip to first unread message
jeff
Dec 20, 2011, 5:27:23 PM12/20/11
to model-glue
In my applications authentication event, we check to see if the user
submitted a form. If they did, we store it in session and then check
for it later after they login, and then push it back into the form
scope.
The idea is this:
1) User just typed in a whole lot of data.
2) << in the mean time, user has timed out>>
3) User submits form, and instead is confronted with a login screen
since they timed out (and we've stored there data into session)
4) user logs in, and is redirected to the "save action".
5) we pull the data out of session, put it back into form, and all is
well.
This works great until file attachments come into play. Railo stores
them in webroot/WEB-INF/railo/temp and the file doesn't seem to exist
after the login.
Is there a best practice way to handle this sort of thing so file
uploads can be preseved?
submitted a form. If they did, we store it in session and then check
for it later after they login, and then push it back into the form
scope.
The idea is this:
1) User just typed in a whole lot of data.
2) << in the mean time, user has timed out>>
3) User submits form, and instead is confronted with a login screen
since they timed out (and we've stored there data into session)
4) user logs in, and is redirected to the "save action".
5) we pull the data out of session, put it back into form, and all is
well.
This works great until file attachments come into play. Railo stores
them in webroot/WEB-INF/railo/temp and the file doesn't seem to exist
after the login.
Is there a best practice way to handle this sort of thing so file
uploads can be preseved?
Dan Wilson
Dec 21, 2011, 8:57:15 AM12/21/11
to model...@googlegroups.com
Well, one idea I have is to just move the file into a temporary location you control, and rename it with something that allows you to retrieve it, and also to remove it after a period of time should it become stale.
--
Plutarch - "The mind is not a vessel to be filled but a fire to be kindled."
Another idea is to rethink how you are holding your IsLoggedIn logic. If you had this in a cookie, you wouldn't really have to worry about the timeout, per se..
I almost never use the session for anything but temporary values. That's because of two reasons:
- The session can timeout, as you are experiencing, causing data loss.
- Sessions are nor very well replicated across machines... especially complex values so if you end up needing a clustered situation and are using complex values, you will either have a refactor on your hands, or run in to lots of trouble as people bounce back and forth between machines.
DW
DW
--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to model...@googlegroups.com
To unsubscribe from this group, send email to
model-glue+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
Plutarch - "The mind is not a vessel to be filled but a fire to be kindled."
Dan Wilson
Dec 21, 2011, 2:24:45 PM12/21/11
to model...@googlegroups.com
This is more of the idea I had in mind for your architecture:
DW
The solution is the shared-nothing architecture, which I first heard of in an interview with Rasmus Lerdorf . What does this architecture involve? Simply not sharing anything. No shared data, at least within the webserver. Sessions are shared, but are shared through the filesystem or database, which can easily be scaled by using a networked filesystem (NFS, SMB) or by using a database.
DW
jeff
Dec 28, 2011, 1:02:08 AM12/28/11
to model-glue
Interesting article, there is a similar thread here:
http://groups.google.com/group/railo/browse_thread/thread/b544ef98b1b78c16
where the solution being proposed is "Use railo's memcached option for
session storage". apparently this is also clusterable.
Although in my case:
1) 99%+ of the visitors to the website cannot and will never be able
to login
2) there is no global application
3) we could afford to sacrifice speed in the admin section (say
decrypting/parsing cookies as you suggest - is that even significantly
slower) on each request as long as that speeds things up for the 99%.
Thanks again for the feedback.
On Dec 21, 12:24 pm, Dan Wilson <sipac...@gmail.com> wrote:
> This is more of the idea I had in mind for your architecture:
>
> http://zef.me/883/the-share-nothing-architecture
>
> The solution is the shared-nothing architecture, which I first heard of in
>
> > an interview with Rasmus Lerdorf . What does this architecture involve?
> > Simply not sharing anything. No shared data, at least within the webserver.
> > Sessions are shared, but are shared through the filesystem or database,
> > which can easily be scaled by using a networked filesystem (NFS, SMB) or by
> > using a database.
>
> DW
>
>
>
>
>
>
>
>
>
> On Wed, Dec 21, 2011 at 8:57 AM, Dan Wilson <sipac...@gmail.com> wrote:
> > Well, one idea I have is to just move the file into a temporary location
> > you control, and rename it with something that allows you to retrieve it,
> > and also to remove it after a period of time should it become stale.
>
> > Another idea is to rethink how you are holding your IsLoggedIn logic. If
> > you had this in a cookie, you wouldn't really have to worry about the
> > timeout, per se..
>
> > I almost never use the session for anything but temporary values. That's
> > because of two reasons:
>
> > - The session can timeout, as you are experiencing, causing data loss.
> > - Sessions are nor very well replicated across machines... especially
http://groups.google.com/group/railo/browse_thread/thread/b544ef98b1b78c16
where the solution being proposed is "Use railo's memcached option for
session storage". apparently this is also clusterable.
Although in my case:
1) 99%+ of the visitors to the website cannot and will never be able
to login
2) there is no global application
3) we could afford to sacrifice speed in the admin section (say
decrypting/parsing cookies as you suggest - is that even significantly
slower) on each request as long as that speeds things up for the 99%.
Thanks again for the feedback.
On Dec 21, 12:24 pm, Dan Wilson <sipac...@gmail.com> wrote:
> This is more of the idea I had in mind for your architecture:
>
> http://zef.me/883/the-share-nothing-architecture
>
> The solution is the shared-nothing architecture, which I first heard of in
>
> > an interview with Rasmus Lerdorf . What does this architecture involve?
> > Simply not sharing anything. No shared data, at least within the webserver.
> > Sessions are shared, but are shared through the filesystem or database,
> > which can easily be scaled by using a networked filesystem (NFS, SMB) or by
> > using a database.
>
> DW
>
>
>
>
>
>
>
>
>
> On Wed, Dec 21, 2011 at 8:57 AM, Dan Wilson <sipac...@gmail.com> wrote:
> > Well, one idea I have is to just move the file into a temporary location
> > you control, and rename it with something that allows you to retrieve it,
> > and also to remove it after a period of time should it become stale.
>
> > Another idea is to rethink how you are holding your IsLoggedIn logic. If
> > you had this in a cookie, you wouldn't really have to worry about the
> > timeout, per se..
>
> > I almost never use the session for anything but temporary values. That's
> > because of two reasons:
>
> > - Sessions are nor very well replicated across machines... especially
> > complex values so if you end up needing a clustered situation and are using
> > complex values, you will either have a refactor on your hands, or run in to
> > lots of trouble as people bounce back and forth between machines.
>
> > DW
>
> > DW
>
> > complex values, you will either have a refactor on your hands, or run in to
> > lots of trouble as people bounce back and forth between machines.
>
> > DW
>
> > DW
>
Reply all
Reply to author
Forward
0 new messages