TheunisP
Posts: 342
|
| Posted: 01/16/2006, 2:27 PM |
|
Hi 1and all, I would really appreciate some help on the logic of logged in status, I want people to be able to stay logged on with cookies (now for most my code works but it does have some problems), here is what I have:
1. Index page which is restricted, must be logged in to see it
2. If not logged in you get pass to pageUserLogin.asp
3. In the login event I have the code that sets the cookies with the a rememberme piece of code that works perfectly
4. The system does have a system wide standard header and footer page
The problem starts when a user leaves the system for a while, the session cookie expires and the user then moves to another page via the menu.
Now CSS checks: aaahhaa! you are not logged in - so I need to to make sure that the user is re-logged in automatically before CSS checks - so I thought the header - before show event, or after init event - but that doesn't seem to work - so please somebody where is the correct place to put my re-login code?
It just doesn't make sense to duplicate the re-login code to all the pages??
Thanks
T
|
 |
 |
peterr
Posts: 5971
|
| Posted: 01/16/2006, 2:38 PM |
|
Maybe just extending the session time would work for you? This forum is now set to not expire logins for 24 hours.
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
TheunisP
Posts: 342
|
| Posted: 01/16/2006, 2:47 PM |
|
Peter, the user has seen a version of login (popular in some forums) that has a dropdown keep login e.g. 1 day, 7 days, month, forever etc etc. - and you guessed it - Client: "I want that..."
|
|
|
|
peterr
Posts: 5971
|
| Posted: 01/16/2006, 3:55 PM |
|
That is little different and we may be discussing two different topics.
If like you previously wrote "user then moves to another page via the menu" then they are still within the same Web browser window. In such case the session time can be extended. And this is the solution that I would recommend.
But allowing users to come back within several days to the Website (or even open the same Website in a new Web browser) means that they will no longer be in the same Web browser session. In such case you can use a different solution, for example create a custom cookie that expires in X days. You can place some code in Common.asp that checks such cookies and creates approperiate UserID/UserLogin/GroupID session variables when needed. There is a related discussion at http://forums.codecharge.com/posts.php?post_id=43134
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
TheunisP
Posts: 342
|
| Posted: 01/16/2006, 4:20 PM |
|
Peter, let's just look at the 1st section of your reply - it is here where my problem actually is - I know that in a perfect world the IIS setting for the time out should work as they say, and that the normal user (99%) will most probably click on something in the app and keep the session alive - but I know that IIS loses state from time to time - e.g. somebody working on the shared server, rebooting, starting and stoppping services, long time periods of inactivity on client side etc etc. So I'll rather not trust IIS to do it for me, or assume a certain beahviour from either the server or user.
As soon as I go solve the above (putting a work arround in and not trusting IIS to keep state), the second portion is automatically solved (by just setting the cookie expiry date)
So, would you suggest that I change my default common.asp to force this behaviour - and then keep in mind that I'll have to make sure from upgrade to upgrade and patch to patch that my changes are still in the common.asp and not overwritten?
PS. The CCS forums actually just proved a point how needed this functionality is, I clicked on your reply in the mail, typed the whole response and assumed that it was posted - ok ok I was paying carefull attention - luckily I saw before closing the window that I wasn't logged in - thus my reply wasn't posted - no username given. Since between my previous post, and this one; I lost my logged in session to the board 
|
|
|
|
Walter Kempees
|
| Posted: 01/16/2006, 4:25 PM |
|
Is it a valid suggestion to put a META refresh in your Header with a long
time (but shorter than cookie expiration time)?
Meaning that as long as the user interacts nothing is triggered but as soon
the user walks away and a (u choose) set number of seconds
passes the page is refreshed by the browser thereby interacting and not
expiring the cookie.
|
|
|
|
TheunisP
Posts: 342
|
| Posted: 01/16/2006, 4:35 PM |
|
Walter, I actually considered doing that as well - but played I have a fair notion that if you click stop in the browser that event stops firing - it also just solves the 1/2 the problem - but gives me the oppurtunity to refresh some data to user as well - which is a appealing idea... maybe a hybrid idea can develop out of this one
Peter, checked Don's thread - that is only 1/2 the solution - he grabs the values, stores it and there it stays - seemingly they didn't come up with a satisfactory solution either
|
|
|
|
peterr
Posts: 5971
|
| Posted: 01/16/2006, 5:10 PM |
|
T,
I think that IIS cannot lose session state unless something is seriously wrong. Rebooting or restarting IIS is a serious problem and could result in various other issues, including incomplete transactions, regardless of session being preserved. "long time periods of inactivity on client side" is the only reason that IIS may lose session state, and that's why extending session time should solve this. And you may want to extend your session expiration anyway since it should improve the Website usability. For example at the beginning/end of Common.asp enter:
Session.Timeout = Minutes (based on http://www.w3schools.com/asp/prop_timeout.asp)
A cookie-based solution should further improve the usability. Possibly the solution discussed on the other thread is not fully polished, but cookie-based solution is probably the maximum and best that you can do. If that cannot provide a full solution than I don't know what could 
After you determine via cookie that the user is still logged in (for example by the fact that cookie hasn't expired) then you would just need to create session variables for UserID/UserLogin/GroupID. There could be additional variations of such solution like using cookies to store user id vs. user login and password, or some other information, in plain or encrypted form, etc. In this case it's probably more difficult to decide on a solution than implement it. Unfortunately I don't have a specific solution but maybe others would describe their approach.
As for placing functions at the end of Common.asp, this is completely safe if you don't modify the generated code. All CCS upgrades only re-generate the code, but don't touch any additional code outside of the grey code areas. But you can also create a separate ASP script with custom functions, then include it at the beginning of Common.asp.
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
TheunisP
Posts: 342
|
| Posted: 01/16/2006, 5:23 PM |
|
Ok, I'm with you and I think I'll get it going now just 2 quickies and then I'm off:
1. So in common.asp can I add code in the grey or white areas - and it won't be overwritten
2. Just give me a heads up on the how the flow works, where does CCS start to validate user log in status - is it in the section where you grab the session variables - so I assume I can change that to cookies statements (I'm in the common.asp file now)
|
|
|
|
Walter Kempees
|
| Posted: 01/16/2006, 5:24 PM |
|
Peterr:
So now you nearly fell in the trap of mixing subject
see Other thread, Comment needed on include........
GNight all
|
|
|
|
Walter Kempees
|
| Posted: 01/16/2006, 5:25 PM |
|
White !!!
|
|
|
|
TheunisP
Posts: 342
|
| Posted: 01/16/2006, 5:37 PM |
|
ahhh - I think I've got it - if I force my cookie values into the Session variables e.g. at the end of common.asp - that should do the trick?
e.g.
Session("UserID") = request.cookie("UserID")
Session("UserLogin = request.cookie(" UserLogin")
Session("GroupID = request.cookie("GroupID")
|
|
|
|
peterr
Posts: 5971
|
| Posted: 01/16/2006, 5:39 PM |
|
T,
You should only modify the white areas, which basically means placing the code at the end of Common.asp. The grey areas can also be occasionally modified if needed, but I don't see such need in this case.
CCS validates page access permission at the beginning of executnig a page. But this should not be relevant in this case and that process can stay working exactly as it already is.
All you need to do is to tell the system that the user is logged in, which is done by creating session variables for UserID/UserLogin/GroupID.
Specifically, all you need to do in Common.asp is to create those session variables when cookie hasn't expired.
A simple test is to type such sample code at the end of Common.asp:
Session("UserID") = 123
Session("UserLogin") = "MyLogin"
Session("GroupID") = 1000
This is all that is needed to "log someone in". No need to look at pages, or understand how things work, or where CCS validates something. Simply create those 3 session variables and you're done.
Then of course you can extend that code to retrieve the user id, login and group from cookies, or from database based on cookies.
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
TheunisP
Posts: 342
|
| Posted: 01/16/2006, 5:39 PM |
|
@Walter
|
|
|
|
peterr
Posts: 5971
|
| Posted: 01/16/2006, 5:42 PM |
|
Yes, that should do the trick in a basic form. It would only be better to encrypt that information in some way that people can't easily modify theie cookie to use someone else's login, or increase their security level (GroupID).
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
TheunisP
Posts: 342
|
| Posted: 01/16/2006, 7:06 PM |
|
Thanks P & W, works like a charm now - nice little drop down with options on how long it should stay logged in and all. Had to use Iif and IsEmpty to setup init values but as said working great now.
Yes, I'll encrypt the values - I know that cookies has this built-in as far as I know so that should be a piece of cake.
Will clean up the code and make it more universal (work with defaults) and post later to tips section
|
|
|
|
Walter Kempees
|
| Posted: 01/16/2006, 7:14 PM |
|
As I said
GNight 04:15
"TheunisP" <TheunisP@forum.codecharge> schreef in bericht
news:643cc5f32445a8@news.codecharge.com...
> Thanks P & W, works like a charm now - nice little drop down with options
> on how
> long it should stay logged in and all. Had to use Iif and IsEmpty to setup
> init
> values but as said working great now.
>
> Yes, I'll encrypt the values - I know that cookies has this built-in as
> far as
> I know so that should be a piece of cake.
>
> Will clean up the code and make it more universal (work with defaults) and
> post
> later to tips section
>
>
> ---------------------------------------
> Sent from YesSoftware forum
> http://forums.codecharge.com/
>
|
|
|
|
Walter Kempees
|
| Posted: 01/16/2006, 7:15 PM |
|
As I said GNight.
My cookie has expired, 04:15
"TheunisP" <TheunisP@forum.codecharge> schreef in bericht
news:643cc5f32445a8@news.codecharge.com...
> Thanks P & W, works like a charm now - nice little drop down with options
> on how
> long it should stay logged in and all. Had to use Iif and IsEmpty to setup
> init
> values but as said working great now.
>
> Yes, I'll encrypt the values - I know that cookies has this built-in as
> far as
> I know so that should be a piece of cake.
>
> Will clean up the code and make it more universal (work with defaults) and
> post
> later to tips section
>
>
> ---------------------------------------
> Sent from YesSoftware forum
> http://forums.codecharge.com/
>
|
|
|
|
TheunisP
Posts: 342
|
| Posted: 01/16/2006, 7:26 PM |
|
Another 24+ hour coding session, how could I fall so far behind Later & thanks again
|
|
|
|
|
