history -1

[Jeff]

I need to make a response.redirect that will take the user back 2 pages
after they login.

How can i implement this into response.redirect ?

Thanks

 

[Bob Barrows [MVP]]

I need to make a response.redirect that will take the user back 2
pages after they login.

How can i implement this into response.redirect ?

It can't be done without saving the pages in a hidden field. The server
knows nothing about the client history.

 

[Jeff]

So there is no way to have on the login page somewhere that says like

past = history.go(-2)

then have <% response.redirect "&past&"%>

or, could i have the login page, after a good login, go to a page that just
has the history.go(-3)

 

[Michael Kujawa]

Has to be a client side redirect
At the end of your routine create a javascript function to handle this
<%
If code works then
%>
<script>
{
window.history.go(-2);
}
</script>
<%
else
end if
%>

 

[Bob Barrows [MVP]]

So there is no way to have on the login page somewhere that says like

past = history.go(-2)

If this is supposed to be server-side code, then no. The server knows
nothing about the client history.
See a client-side newsgroup such as m.p.scripting.jscript for help with
populating a hidden field on a form with the items in history (perhaps in an
xml string, but not required).

Server-side code can read the contents of the hidden field and do what needs
to be done.

 

[Bob Barrows [MVP]]

So there is no way to have on the login page somewhere that says like

past = history.go(-2)

then have <% response.redirect "&past&"%>

or, could i have the login page, after a good login, go to a page
that just has the history.go(-3)

I take it back. There is a way to do it in server-side code: write a
client-side script block to the Response. Air code:

<%
If successfulLogin then
response.write "<script type=""text/javascript"">
response.write "history.go(-2);</script>
end if
%>

 

[Jeff]

Thanks bob. This is working.. sortof. Here is the delema.

I have a report page with this at the top

if session("loggedin")<>1 then response.redirect "login.asp"

the login script sets the session to 1 if they are logged in, and lets them
view this page. if it isn't 1, then it sends them to the login page.

the problem is this, when it goes back 2 in history, it skips over that
report page, and goes to the page that I clicked report on. if i set it
to -1, it goes back to the login page. so it is missing the page that
redirected it to begin with.

am i doing something wrong?

 

[Mike Brind]

If Session("loggedin")<>1 Then
Session("redirect") = Request.ServerVariables("SCRIPT_NAME")
Response.Redirect "login.asp"
End If

Then in the login page, on successful log in:

If Session("redirect")<>"" Then
redirectpage = Session("redirect")
Session("redirect")=""
Response.Redirect redirectpage
End If

 

[Bob Barrows [MVP]]

Thanks bob. This is working.. sortof. Here is the delema.

I have a report page with this at the top

if session("loggedin")<>1 then response.redirect "login.asp"

the login script sets the session to 1 if they are logged in, and
lets them view this page. if it isn't 1, then it sends them to the
login page.
the problem is this, when it goes back 2 in history, it skips over
that report page, and goes to the page that I clicked report on. if i
set it to -1, it goes back to the login page. so it is missing the page
that
redirected it to begin with.

am i doing something wrong?

No, that's the problem with using History, which can cause pages to be
retrieved from the browser cacne rather than being re-requested from the
server.

You need to rethink what you are doing. At the very least, store the name of
the page you need to go back to in a session variable. Consider using
Server.Transfer instead of Response.Redirect to prevent pages from being
retrieved from the browser cache.

if session("loggedin")<>1 then
session("PageWhereAuthFailed") = "me.asp"
response.redirect "login.asp"
end if

in login.asp:
if SuccessfulLogin then
session("loggedin")=1
pageForm = session("PageWhereAuthFailed")
session("PageWhereAuthFailed") = ""
if len(pageFrom)>0 then
Server.Transfer(pageFrom)
else
'do the default action
end if
end if

 

[Evertjan.]

Jeff wrote on 19 mei 2006 in microsoft.public.inetserver.asp.general:

hanks bob. This is working.. sortof. Here is the delema.

I have a report page with this at the top

if session("loggedin")<>1 then response.redirect "login.asp"

the login script sets the session to 1 if they are logged in, and lets
them view this page. if it isn't 1, then it sends them to the login
page.

the problem is this, when it goes back 2 in history, it skips over
that report page, and goes to the page that I clicked report on. if i
set it to -1, it goes back to the login page. so it is missing the
page that redirected it to begin with.

am i doing something wrong?

I prefer serverside session memory over clienside history:

if session("loggedin") <> 1 then
session("origin") = request.servervariables("URL")
response.redirect "login.asp"
end if

And a successful login will do:

response.redirect session("origin")

===========

Another way is to build the login code
as an include to every page top:


========= login.include.asp =============
<%
if request.form("password") <> "" then
do your autentication things
and set session("loggedin") to 1 if ok.
end if

if session("loggedin") <> 1 then
%>
<html>
<form method=post>
do the login html form things
....
</html>
<%
response.end
end if
%>

 

[Jeff]

I tried both of your ways, and they both work perfectly.
I prefer Mike's way, simply because I wouldn't have to change the
session("PageWhereAuthFailed") on each page that is protected.

You guys are truley the best at what you do, and you help and advice is
always appreciated.

Thanks
Jeff

 

[Dave Anderson]

I tried both of your ways, and they both work perfectly.
I prefer Mike's way, simply because I wouldn't have to
change the session("PageWhereAuthFailed") on each page
that is protected.

That technique should work fine unless/until you extend your login to span
multiple applications, technologies, servers or domains.

We built an enterprise-wide session architecture that allows ASP, JSP and
ASP.NET to share sessions (authentication as well as variables). We
authenticate under SSL against an NDS tree[1], and the individual
applications are a mix of SSL and non-SSL, depending on their sensitivity.
As you can imagine, this means the session information is kept in a
database, rather than on the web servers.

The ASP implementation is unsurprisingly the least elegant of the bunch, as
well as the most perturbable. We have distilled it to a Server.Execute()
call for each protected page. If/when you extend your login and can't figure
out how to proceed, post back here and I can probably offer some suggestions
based on lessons learned.



[1] This could just as easily be against AD.

 

[Jeff]

I will do that. Thanks so much for the help.
Jeff

I tried both of your ways, and they both work perfectly.
I prefer Mike's way, simply because I wouldn't have to
change the session("PageWhereAuthFailed") on each page
that is protected.

That technique should work fine unless/until you extend your login to span
multiple applications, technologies, servers or domains.

We built an enterprise-wide session architecture that allows ASP, JSP and
ASP.NET to share sessions (authentication as well as variables). We
authenticate under SSL against an NDS tree[1], and the individual
applications are a mix of SSL and non-SSL, depending on their sensitivity.
As you can imagine, this means the session information is kept in a
database, rather than on the web servers.

The ASP implementation is unsurprisingly the least elegant of the bunch,
as well as the most perturbable. We have distilled it to a
Server.Execute() call for each protected page. If/when you extend your
login and can't figure out how to proceed, post back here and I can
probably offer some suggestions based on lessons learned.



[1] This could just as easily be against AD.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message.
Use of this email address implies consent to these terms.