Referring page
Shashank
to delete an entity. The confirmation form contains a 'yes' and 'no'
button. If the user presses yes, then the entity is deleted, no
problems there. But if the user presses 'no', she should be taken back
to the original page from where the delete call was made. Now I
thought about using the function redirect, but there are two pages
that lead to this 'delete' page. Hence, I don't know where to redirect
the user back to. So is there a way to know that. I looked at the api,
but didn't find the function that could help.
Adam Kittelson
redirect request.env.fetch("HTTP_REFERER")
-Adam
Shashank
charm. :).
Is there a documentation for such hashes. Didn't find it on Ramaze
documentation. I use the hash 'request' to get form field names and
values. Never heard of env. And there isn't a book on Ramaze (yet).
On Jul 14, 2:49 pm, "Adam Kittelson" <adam.kittel...@apathydrive.com>
wrote:
> request object. There are two hashes in there, params (all the form field
> names and values), and env, which has neat things like the http referrer, so
> this should work:
>
> redirect request.env.fetch("HTTP_REFERER")
>
> -Adam
>
Shashank
login page of the website if they aren't logged in, and recording the
referring page with request.env.fetch("HTTP_REFERER") . I'm using
'redirect' function to redirect them to the login page. The problem
here is, if the user types in the address to a restricted page, then I
get an exception from my login page - "key not found", which I believe
is referring to the key "HTTP_REFERER". Also, even if the user clicks
on a link that would require him/her to login, after logging in they
are taken to the original page. So suppose page1 is open to all, page2
is restricted, but page1 links to page2. When the user clicks the
link, she's taken to page2, but since she's not logged in, it
redirects to the loginpage. The user logs in, but is now redirected
back to page1, while I expected it to be page2. Is there a way to get
around this?
> request object. There are two hashes in there, params (all the form field
> names and values), and env, which has neat things like the http referrer, so
> this should work:
>
> redirect request.env.fetch("HTTP_REFERER")
>
> -Adam
>
ara.t.howard
On Jul 15, 2008, at 10:54 AM, Shashank wrote:
>
> As a follow up, I've got another problem. I'm redirecting users to the
> login page of the website if they aren't logged in, and recording the
> referring page with request.env.fetch("HTTP_REFERER") . I'm using
> 'redirect' function to redirect them to the login page. The problem
> here is, if the user types in the address to a restricted page, then I
> get an exception from my login page - "key not found", which I believe
> is referring to the key "HTTP_REFERER". Also, even if the user clicks
> on a link that would require him/her to login, after logging in they
> are taken to the original page. So suppose page1 is open to all, page2
> is restricted, but page1 links to page2. When the user clicks the
> link, she's taken to page2, but since she's not logged in, it
> redirects to the loginpage. The user logs in, but is now redirected
> back to page1, while I expected it to be page2. Is there a way to get
> around this?
1 - never use HTTP_REFERRER like that, you open yourself up for cross-
site scripting. use
URI.parse(ENV['HTTP_REFERRER']).path
or simiilar. in other words be careful about the host
to solve your link and back issues this is what i do
1 - at the end of any request (after filter) track http_referrer in
the session. never use the hostname.
def http_referrer
...
end
you have to get fancy when http and https are involved
2 - when starting a login cycle, directory or due to redirection,
start tracking where the user is logging in from thusly
session[ 'logging_in_from' ] ||= http_referrer
3 - once the use has successfully logged in you can do
back = session[ 'logging_in_from' ] || '/'
session[ 'logging_in_from' ] = nil
redirect back
this solves a ton of issues you'll have using only http_referrer, for
example when the user fails to enter the password correctly then
http_referrer will be the login page itself, forcing the user into and
endless cycle. in fact this case should be protected against anyhow.
cheers.
a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama
sam carr
It's a simple mechanism that allows you to put data on a stack, that
is stored on the session. So, when you finish one 'sidetrack' activity
(e.g. login) you can pop off the stack and determine what original
activity to redirect back to.
This is from memory, so I may have some of the details wrong.
ara.t.howard
yeah i almost used that, but anything that appends into a session
infinitely without bound does open one up for DOS attacks... 2 cts.
Michael Fellinger
>
>
> On Jul 15, 2008, at 1:48 PM, sam carr wrote:
>
>> Ramaze has a 'stack' helper that may be of some use here, I think.
>> It's a simple mechanism that allows you to put data on a stack, that
>> is stored on the session. So, when you finish one 'sidetrack' activity
>> (e.g. login) you can pop off the stack and determine what original
>> activity to redirect back to.
>>
>> This is from memory, so I may have some of the details wrong.
>
>
>
> yeah i almost used that, but anything that appends into a session
> infinitely without bound does open one up for DOS attacks... 2 cts.
True that, wanna patch it? :)
Also, the idea with not using domain ain't fully reliable, as some
people will try to use it over multiple domains... I'm not sure which
path to use, only that the one we take right now is KISS from an
implementation perspective but requires definitely more warning signs.
^ manveru
ara.t.howard
On Jul 15, 2008, at 3:50 PM, Michael Fellinger wrote:
> True that, wanna patch it? :)
boy do i! unfortunately stuck with a ton of rails work and 0 dollars
in the bank account (literally)
/me mutters
>
> Also, the idea with not using domain ain't fully reliable, as some
> people will try to use it over multiple domains... I'm not sure which
> path to use, only that the one we take right now is KISS from an
> implementation perspective but requires definitely more warning signs.
i think you're correct there. definite sometimes have to handle a few
domains - just wanted to point out that blindly using HTTP_REFERRER is
bad for security and correctness (speaking from experience
unfortunately)
hope all's well with you.
kind regards.
Shashank
'URI.parse(ENV['HTTP_REFERRER']).path' to get the path name, but now I
get error that says 'bad URI(is not URI?):'. I've required 'uri' and
'uri/http'. I even tried changing the name of 'HTTP_REFERRER' to
'HTTP_REFERER' (single R), but no success.
Good suggestions though. I'll try to implement all of them. A stack
approach sounds to be a pretty good idea.
ara.t.howard
On Jul 17, 2008, at 8:48 AM, Shashank wrote:
>
> Thanks for your suggestions. I tried the
> 'URI.parse(ENV['HTTP_REFERRER']).path' to get the path name, but now I
> get error that says 'bad URI(is not URI?):'. I've required 'uri' and
> 'uri/http'. I even tried changing the name of 'HTTP_REFERRER' to
> 'HTTP_REFERER' (single R), but no success.
>
> Good suggestions though. I'll try to implement all of them. A stack
> approach sounds to be a pretty good idea.
that environment var is not always set, you have to handle that case.
from a rails' app: