Hi,
Suppose I have a resource such as http://localhost:3000/topsecret/data
that requires the user to login first.
What I did was make use of before_filter to check and see if the session
variable is set with the logged in user’s id (similar to the example in
“Agile Web D. with Rails”).
However while the filtering function does work correctly in redirecting
the user to the login page, how do I actually capture the original
request made by the user so that I can redirect the user back to the
required resource after s/he has logged in?
Thanks!
For doing this I usually use a session[]. The user tries to login, and
if
it’s not authenticated the authentication method stores the
“intended_controller” in a session[]. Then when the user logs in the
system the login method redirects to the previously intended controller.
Hope that helps,
Francesc
##########################################
The Admin controller
##########################################
before_filter :authentication
def authentication
unless session[:user]
session[:intended_controller] = ‘/admin/’ + controller_name
redirect_to :controller => ‘/account’
end
end
#########################################
The account controller
#########################################
def login
Here comes the login code …
if # login is successful …
redirect_to session[:current_page]
else
redirect_to ‘/account/login’
end
–
name. Francesc E.
email. [email protected]
On Mar 21, 2006, at 11:36, Woei S. wrote:
redirecting
the user to the login page, how do I actually capture the original
request made by the user so that I can redirect the user back to the
required resource after s/he has logged in?
acts_as_authenticated[*] does this out of the box. However, if you
want to write your own system take a look at the method
redirect_back_or_default here
http://tinyurl.com/m62y5
– fxn
[*] http://wiki.rubyonrails.org/rails/pages/Acts_as_authenticated
Xavier N. wrote:
On Mar 21, 2006, at 11:36, Woei S. wrote:
redirecting
the user to the login page, how do I actually capture the original
request made by the user so that I can redirect the user back to the
required resource after s/he has logged in?
acts_as_authenticated[*] does this out of the box. However, if you
want to write your own system take a look at the method
redirect_back_or_default here
http://tinyurl.com/m62y5
– fxn
[*] http://wiki.rubyonrails.org/rails/pages/Acts_as_authenticated
Just curious, is it possible to extend this further such that if the
original request was a HTTP POST, that POST request and with all its
form values could be “repeated” after the user logs in?
Woei S. wrote:
http://tinyurl.com/m62y5
– fxn
[*] http://wiki.rubyonrails.org/rails/pages/Acts_as_authenticated
Just curious, is it possible to extend this further such that if the
original request was a HTTP POST, that POST request and with all its
form values could be “repeated” after the user logs in?
When would you have access to a form but not the URL it posts to?
Jeroen
Jeroen H. wrote:
When would you have access to a form but not the URL it posts to?
Jeroen
Using ruby-forum as an example, let’s say I’ve clicked on the “reply”
and halfway through a reply I went off elsewhere and hours later I came
back, completed my post, submitted, and realises that my session has
timed out 
Jeroen H. wrote:
When would you have access to a form but not the URL it posts to?
When your session times out while editing the form?
–
View this message in context:
http://www.nabble.com/"Remembering"-link-to-redirect-to-after-logging-in-t1316628.html#a3511039
Sent from the RubyOnRails Users forum at Nabble.com.
Woei S. wrote:
However while the filtering function does work correctly in redirecting
the user to the login page, how do I actually capture the original
request made by the user so that I can redirect the user back to the
required resource after s/he has logged in?
Thanks!
See page 130/131 in awdr. There’s an example which works by storing
request.parameters in a session variable in your auth filter, then
redirecting to it (or :action => “index”, should the session variable be
nil) on successful login.
–
View this message in context:
http://www.nabble.com/"Remembering"-link-to-redirect-to-after-logging-in-t1316628.html#a3511226
Sent from the RubyOnRails Users forum at Nabble.com.
Lucifron wrote:
Jeroen H. wrote:
When would you have access to a form but not the URL it posts to?
When your session times out while editing the form?
Yes that’s indeed a valid scenario. It’s a rare case though so I
wouldn’t write any code to handle such a rare case, but that’s just my
opinion of course
Jeroen
Lucifron wrote:
However while the filtering function does work correctly in redirecting
the user to the login page, how do I actually capture the original
request made by the user so that I can redirect the user back to the
required resource after s/he has logged in?
Thanks!
See page 130/131 in awdr. There’s an example which works by storing
request.parameters in a session variable in your auth filter, then
redirecting to it (or :action => “index”, should the session variable be
nil) on successful login.
I’m not sure about storing it in the session. It may well work just
fine, but I just use a hidden form field to remember the original
request URI because I think storing stuff like that in the session is
going to backfire sooner or later. But maybe I’m just being conservative
Jeroen
Woei S. wrote:
What’s funnier is the parameters got completely borked
Parameters: {“user”=>“usernameasd1lock_version0password”,
“commit”=>“Edit”, “id”=>“3”}
(the username was asd1 and the rest and pretty self explainatory)
What went wrong here?
Looks like a hash got flattened to a string.
{:a => ‘1’, :b => ‘2’}.to_s ==> ‘a1b2’
You’re not doing an <%= @params %> (or something to that effect) in a
hidden field in your login form, are you?
Jeroen H. wrote:
Lucifron wrote:
Yes that’s indeed a valid scenario. It’s a rare case though so I
wouldn’t write any code to handle such a rare case, but that’s just my
opinion of course
Jeroen
Heh that’s true, it’s nothing serious, I’m just doing it cos I want to
figure out how it is done.
Ironically it turned out that the solution I hacked out was similar to
the one in AWDWR but I keep getting an error.
undefined method `stringify_keys!’ for
“usernameasd1lock_version0password”:String
What I did was log in, go to a scaffold page to display an edit form,
log out, and then submit the edited form. Sure enough I got redirected
to the login form, but after I logged on it spit out that error.
What’s funnier is the parameters got completely borked
Parameters: {“user”=>“usernameasd1lock_version0password”,
“commit”=>“Edit”, “id”=>“3”}
(the username was asd1 and the rest and pretty self explainatory)
What went wrong here?
Woei S. wrote:
Any chance that when I did the assignment to the session variable that
Ruby somehow casted the hash into a string?
That’d be my guess, but I haven’t the code here to check. You could
try:
session[:forward] = YAML::dump(params)
and then:
redirect_to YAML::load(session[:forward])
or something along those lines. There may well be a slicker way, but
that should, at least, stop string casting from getting in the way.
–
Alex
Alex Y. wrote:
Woei S. wrote:
What’s funnier is the parameters got completely borked
Parameters: {“user”=>“usernameasd1lock_version0password”,
“commit”=>“Edit”, “id”=>“3”}
(the username was asd1 and the rest and pretty self explainatory)
What went wrong here?
Looks like a hash got flattened to a string.
{:a => ‘1’, :b => ‘2’}.to_s ==> ‘a1b2’
You’re not doing an <%= @params %> (or something to that effect) in a
hidden field in your login form, are you?
Nope, what I did was to store request.parameters into a session variable
when the user is redirected and then attempt to do a redirect to that
stored hash value when the user has logged in.
Any chance that when I did the assignment to the session variable that
Ruby somehow casted the hash into a string?