Previous Thread
Next Thread
Print Thread
Rate Thread
Page 1 of 2 1 2
Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
LOGIN.CGI - Version 3.0 [New Public Release]
By Jim Goldbloom [email protected]

Release date: 01/06/01 9:00PM

Folks, version 3 supports full SSI hacking with redirect back to source URL after forced login, including support for those who use HTML frames. If a user visits a link to a forum topic without logging in first (i.e clicking on a link sent in email reply notification) they will be displayed a warning they must login, then after they login they'll be sent back to the forum topic page. That's part of the SSI hack. Also finished guest login restrictions and logging output screens.

Also added many new hacks to secure up UBB and updated the docs. Many cosmetic changes and timing changes to the redirect screens and logs. This public version is the culmination of countless suggestions and testing and I am actually running out of ideas. Very, very stable and beta tested. No hack is ever perfect, but 3.0 has all my original ideas without anything missing. I am proud of this version.

If you're upgrading, get this latest version, I updated the hacks and docs to assist with upgrading.

Full features listing in 3.00 public:

* authenticates username/pass with UBB member files
* catches/logs ALL invalid/missing/illegal logins
* full support for IP ban list in CP
* login username displayed in UBB; logout prompt hack
* full support for guest login mode
* support for registration screen (new members)
* support for lost password function in UBB
* when posting, username/pass fields *always*
filled in automatically even if other cookies expire
* guests are restricted from posting - full control
* custom entry point login screen integration for
unique online experience for your users
* automated logging (creates browser viewable HTML)
including date/time/user/IP/hostname lookup
and ability to disable events as you wish
* optional SSI support for max. data protection
(such as accessing UBB HTML topics/forums) with
registered user auto-redirect after login
* forced/manual login/logout, integrated into UBB
* allow custom private forum/screen redirect to
expand functionality of your UBB
* demo screens included in release archive
* full documentation and examples in archive
for UBB hacks, login screen demo, SSI setup
* friendly login-setup.txt - new and improved
* very streamlined UBB hacks, easy to install
* redirects have sensible timing delays

See it in action:
http://www.accessdeniedbbs.net
(support forum in place on the BBS)

Download the latest files/zip from:
http://www.accessdeniedbbs.net/downloads

I have all the hacks running on my BBS. I'm not online to the public yet, will be soon, so feel free to check it out if you wish. Remember, if you test my SSI - you must be a registered user to see the redirect in action. I disabled it for guests intentionally, as a security measure. I've had people try it after registering and say, simply, "wow." Uh huh. I even saw some of you try to hack your way into my BBS and fail miserably. Bless all you UBB webmasters for trying!

What is LOGIN.CGI?

This is a VERY serious and powerful script/integrated UBB hack for those who want to control access to their UBB, design a unique login screen to serve as one entry point for all your users. It allows you to integrate more personality into the UBB than you ever had before and also restrict access if you run sensitive data. Or, if you want folks to login first and have their username and pasword *always* filled in when posting (no worry with expired username/password cookies.) The cookies are session only, independantly controlled, and all redirect HTML screens are customized by you for complete uniqueness and control of your users. Give your BBS personality. Numerous login actions and HTML files can be configured to integrate with default UBB options also - very easy to setup.

Please visit the download site and examine the help files and example files. The zip is also available for download or view the scripts directly on the site. I even included a demo login screen (to view source of only) and demo log output.

This script has nothing at all to do with any previous releases of login hack/login.cgi by Dave Downin - but his original script inspired me and many thanks to him. My script is a separate UBB hack.

Thank you to Wraith, Allan, other UBB sysops for helping out, and for the excellent word of mouth and postings about this on other UBB Hack BBS's and support forums.

Enjoy, and feedback always appreciated.
If you wish to become a beta tester, send me email please! I need beta testers for 4.x!



------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

Sponsored Links
Joined: Aug 2000
Posts: 569
Member
Member
Offline
Joined: Aug 2000
Posts: 569
Thanks, installing now

------------------
I Disappear ?
http://www.Metallifukinca.com

Joined: Oct 2000
Posts: 565
Member
Member
Offline
Joined: Oct 2000
Posts: 565
Awesome! thanks dude!

------------------
www.skinningworld.net

Joined: Mar 2000
Posts: 63
Member
Member
Offline
Joined: Mar 2000
Posts: 63
First: excellent hack - very well done [Linked Image]

I've read the install instructions, but I I can't put &ConfirmLogin; BEFORE any print statements in postings.cgi because 'print' is on the 1st line. This is what I have:

Code
code:

Thus I am getting the 'Location:xxxx' error described here:

The reason it must be inserted before any print statements is the script
will use a "Location: xxxx" header sent to the web server and that can't happen
if text or a header already was displayed. Otherwise our header outputs as text
and the user will see "Location: xxxx" on their browser screen. Big oops.


Any help greatly appreciated. Thanx again.


This message has been edited by spiffy on January 08, 2001 at 10:28 AM

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Simply move that print statement "print ("Content-type: text/htmlnn"); " directly below the &Confirmlogin; that's all. Insert it there if necessary or cut/paste it to the new location. It's been awhile since I checked the factory edition of ubb_library.pl but I think that print statement does NOT reside at that position by default. I could be wrong, heck, I hacked my scripts a zillion times by the time I wrote my docs, heh.

You may notice that in most UBB scripts that print statement and also &ReadParse is towards the top. The print statement sets up the HTML headers and the &ReadParse function reads the environment and arguments passed to the script from other scripts. My hack line &ConfirmLogin; must be anywhere after the require statements and anywhere before the first print and &ReadParse statements, that's all. This is your extended answer.

Take care and thanks for the nice words from you and others in this thread!

-Jim


------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

This message has been edited by hate98 on January 08, 2001 at 10:53 AM

Sponsored Links
Joined: Dec 2000
Posts: 4
Junior Member
Junior Member
Offline
Joined: Dec 2000
Posts: 4
Hi Jim. This mod looks great. I just have one quick question before I install it.

Because of another mod (private messages), the cookies for my ubb don't work very well anymore. This goes for both remebering the username of members as well as the last time they logged in. Resetting cookies works for about a day until they're not working again.

Do you think your mod may get these cookies working again? I am just wondering if your coding that controls cookies will replace whatever isn't working about mine. Thanks

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Quote
quote:
Thanks for asking! login.cgi is guaranteed to set the username and password cookies 100%, each and every time someone logs in. This has *completely* solved a problem with those cookies because I use a reliable external Perl library that sets the cookie path as root, does not set expiration and is session only. Each login means brand new username and password cookies, so it's not retrieving cookies, it's SETTING them. I'm glad you asked that because this was a side benefit of the script among it's many other uses. I actually mention this in the docs.

However, login.cgi does NOT effect any other UBB cookies such as last time visited, etc., so any troubles with those cookies are UBB caused. This means that my script "fixes" username and password cookis only, per se. The last time visited cookies and others (private forums, preferences and such) are 100% UBB controlled - please be informed.

I also added a hack to the delete cookies UBB routine (deleting cookies via preference link in UBB) so the session cookie login.cgi sets ("authorized")when a user logs in does not get axed forcing them to logout. But this does not fix anything else wrong with UBB cookie functions.

I have not received any bug reports from folks yet with regards to cookie problems of any kind handled by login.cgi. I expect the script to help you with the two cookies, username and password, in this regard based on my experience and feedback of beta testers.

Hope this answers your question. Of course you'll need to let me know your exprience with this, so email [email protected] if problems after you get it running.

-Jim

------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

This message has been edited by hate98 on January 08, 2001 at 02:22 PM

Joined: Nov 2000
Posts: 467
Code Monkey
Code Monkey
Offline
Joined: Nov 2000
Posts: 467
I have been updating this hack for about the last 4 updates and something I have noticed
(You really got to work to find this however)
If I bookmark posting and dont login but use the bookmark try to post instead of sending me to my forced logout page I get a white screen with this at the top.Location:http://www.esteroumc.com/scripts/cgi-bin/login.cgi?action=forcelogout
Does anyone else get this or is it normal.
My board will go to the forced logout page if I bookmark ultimate.cgi


------------------
SPEED
Just A Thought Christian Chat

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Quote
quote:
Not a script error, speed...

All you need to do is relocate print"Content-type: text/htmlnn"; (called the content type header) to a position just *below* the &ConfirmLogin; that's all. Cut and paste it, that's not adding or removing - that's relocating. :-)

From the docs:
--- snip ---
The reason it must be inserted before any print statements is the script
will use a "Location: xxxx" header sent to the web server and that can't happen
if text or a header already was displayed. Otherwise our header outputs as text
and the user will see "Location: xxxx" on their browser screen. Big oops.
--- snip ---

---snip---
just make sure &ConfirmLogin; is located below the require
lines and BEFORE any other lines.
--- snip ---

The example snippet in the docs was only that, an example and clearly stated so - not everyone's UBB scripts are the same due to hacks and varying versions, etc., so some content headers may be in different places for you vs. for someone else.

This is the most common "bug" report I get, and it's not a bug at all.

-jim



------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

Joined: Nov 2000
Posts: 467
Code Monkey
Code Monkey
Offline
Joined: Nov 2000
Posts: 467
HEY I got it what files do you reccomend adding this too.
------------------
SPEED
Just A Thought Christian Chat

This message has been edited by speed on January 08, 2001 at 10:46 PM

Sponsored Links
Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Speed:

Check further UP in postings.cgi (for example), above the require lines, you will see:

print"Content-type: text/htmlnn";

Relocate it by cut/pasting directly below &ConfirmLogin; please. The print statement you are referring to is not the content header or the first print statement in your file. :-)

Here is my actual postings.cgi to assist you:

Code
code:

-jim



------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

Joined: Nov 2000
Posts: 467
Code Monkey
Code Monkey
Offline
Joined: Nov 2000
Posts: 467
I didnt have it that way before but I updated my pm3.8 hack they moved a line on me, oops that is the only three files I have added that to do you reccomend any more. I didnt think that done that when I first installed the hack.

------------------
SPEED
Just A Thought Christian Chat

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Quote
quote:
So now you see this is not a bug, right?

As I stated before "not everyone's UBB scripts are the same due to hacks and varying versions, etc., so some content headers may be in different places for you vs. for someone else."

So the moral of the story is if you see a content header such as print ("Content-type: text/htmlnn"); at the very top of the file due to some other hack, simply relocate it below &ConfirmLogin; and all hacks will work including mine.

Speed, it's up to you to check this for each UBB script you opt to hack. Based on your original message about this, only postings.cgi seems to have been affacted but if you use my hack in other scripts, check 'em all out just to be sure - only you can do that and it takes 5 mins to fix once you know what to fix (as you do now.)

[Linked Image] I think you're following me now, so if you have further issues - please email them privately to me so the other folks here can ask questions via equal time. Glad I could help, speed. Enjoy login.cgi.

-jim



------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

Joined: Nov 2000
Posts: 51
Member
Member
Offline
Joined: Nov 2000
Posts: 51
Hi,

Great hack! One thing I have noticed though. Sometimes when your moving between forums, it takes you back to the login page. This also happens if you perform other actions such as deleting posts, etc. Any idea why this would happen?

AgentX

Joined: Nov 2000
Posts: 51
Member
Member
Offline
Joined: Nov 2000
Posts: 51
Okay I noticed this...

If your at the Ultimate.cgi url using this URL:

/Ultimate.cgi?action=intro&BypassCookie=true

And you refresh a couple of times, it seems to get confused and jumps you back to the login page.

However, if your at this URL:

/Ultimate.cgi?action=intro

And refresh a couple of times, it always remembers that your there. Is it just me or is this a bug?

AgentX

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Quote
quote:
You're the first to report that type of problem, so my guess is you're having cookie problems. The script will only force log you out if a session only cookie named "authorized" disappears. As you know 3.0 includes a hack to prevent this from happening when you delete cookies in preferences. So I am guessing you have another hack that may be messing with cookies when it should not be, or your browser is fubar. If your users are not experiencing this and you are, you know it's your browser and not the script.

I want to stress that I intentionally chose to use an external perl cookie library, plus a unique session only cookie, to *ensure* compatibility with other well written hacks, and also not to affect cookies generated by UBB. I had foresight with respect to cookies is my point. ;-)

-jim



------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
see response below if running the script on NT

This message has been edited by hate98 on January 11, 2001 at 02:56 PM

Joined: Nov 2000
Posts: 51
Member
Member
Offline
Joined: Nov 2000
Posts: 51
>As a side note - do what UBB docs suggest, >delete your cookies and start 'em over >using the preferences link when logged in. >If the problem goes away, even if for 5 >minutes, you'll know it's your browser >corrupting your cookies. I advise the same >troubleshooting procedure.

I have done this, several times infact, and it does not solve the problem. I uploaded your script to my UBB, and almost everyone who viewed the UBB that day had problems with it. Upon refreshing the page, the user will get booted back to the login page, or even jumping between different forums/posts will result in the same effect. What do you think?

AgentX

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
see response below if you run the script on NT

This message has been edited by hate98 on January 11, 2001 at 02:55 PM

Joined: Mar 2000
Posts: 63
Member
Member
Offline
Joined: Mar 2000
Posts: 63
Hi, I'm having problem with Netscape 4.7/NT where enter my details and I get the intermediary page 'processing' and then am shunted back to login. So, I deleted ALL my cookies and then tried again. When I tried to login, same thing happens, and NO cookies are written to my disk.

Any ideas much appreciated. Ta.

Joined: Mar 2000
Posts: 63
Member
Member
Offline
Joined: Mar 2000
Posts: 63
...just looked at log, and says:

Forced Logout: [Did not login]

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
see the response below about NT

This message has been edited by hate98 on January 11, 2001 at 02:54 PM

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
workin on it...wait for next response please

This message has been edited by hate98 on January 11, 2001 at 02:59 PM

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Quote
quote:
I just thought of something. You did not specify if your SERVER was NT, I assumed you meant the client when accessing the site.

Try this if you have NT (any form) hosting the script:

Make the cookie path in perl-cookie.lib to be the root directory of your hard disk, i.e. "c:" and see if that helps. If not, comment that line our or set to '' (nothing) and see if that helps. You can also specify a custom directory (i.e. c:/path/cookies) as a test. You get what I am saying? Use anything but what's in there now.

It just struck me that the default path in perl-cookie.lib is "/" which is Unix notation and that may screw up the cookie creation for NT boxes hosting the script.

If you run Unix, do NOT touch that file and my guess here does not apply to you.

If this turns out to be the culprit, I'll include this in the docs in next release.

-jim


------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

This message has been edited by hate98 on January 11, 2001 at 03:08 PM

Joined: Mar 2000
Posts: 63
Member
Member
Offline
Joined: Mar 2000
Posts: 63
Yeah, I now agree, I'm inclined to think the problem is with us, as I've just tested it on:

NS4.08/W95 (works)
NS4.7/NTSERVER (works)
NS4.7/NTWKSTATION (not woking yet, but I'm sure it will)

Tomorrow I'll test on other S4.7/NTWKSTATION machine in other offices and get back to you.

Thanks H for all your good work...

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Thanks a million, spiffy and others
agentx - i think this affects you too

spiffy, please note in unix that cookie path must be set to root '/' in Unix notation for ANY scripts (including mine) to read cookies *when called via SSI*. So please let me know what setting works best for you if you run the SSI hack for an NT equivelant setting. In other words I'll need to know if "c:" (i.e. drive: so root is used) works with and also without SSI error free?

In restrospect, this is totally my fault for not thinking of you NT folks, so my bad and my apologies.


------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

This message has been edited by hate98 on January 11, 2001 at 07:38 PM

Joined: Sep 2000
Posts: 37
Member
Member
Offline
Joined: Sep 2000
Posts: 37
You say that you set your cookies as root.

What happens if (as I have) the UBB option is set to use local scope cookies (cgi-bin)?

Is your code going to make the cookies situation worse in this case?

You should document that as a requirement for your hack, if it is true that UBB cookie scope must be set to broad (root) with this hack.

I should add that if I use this hack, it will be as NON-SSI, since my site gets around 80,000 hits per day.

To my thinking, a medium UBB site would be around 1 million hits a month, not 100,000 as you suggest.

This message has been edited by Pilot on January 11, 2001 at 03:19 PM

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Pilot:

First off, thank you for your comments. The reply that follows is very important and I hope everyone following this thread can use this one message as a summary to answer ALL concerns.

This is not really a bug, but a mental breakdown on my part when I created the docs, and here is a detailed explanation about cookies, my script, SSI, Unix and NT:

The cookie routine I use is external to UBB, does not affect UBB cookies at all. It creates 3 session only cookies - UserName, Password and authorized. The last one, if missing, will log the user out. This is what happened to the NT folks due to my error updating the docs.

The issue being discussed in this thread is about the default cookie path set in perl-cookie.lib. Remember my login script actually **fixes** problems with two cookies: UserName and Password, because it *creates* them after any successful login so the user will **always** see these fields filled in when posting messages, etc., even if other 1 year old cookies generated by UBB fail (preferences, private forums, etc.) I don't touch that other cookies at all. The CP settings for cookies has no bearing on my script, or vice versa since I use an external library. This is stated in docs.

Pilot, I want to be VERY clear on that point, to answer your concerns. Take a moment to stop and think about it, it's important you see that distinction.

What follows next is a summary of the discussion taking place in this thead.

First off, a little background:

When SSI is used in a Unix environment, along with cookie support, the cookie MUST be set to root path. This has nothing to do with my script in particular, this is a technical requirement of ALL Unix compatible or cloned servers, plain and simple. In my perl-cookie.lib I set the default path to "/" which works on 100% on the Unix or Unix like systems out there, be it they run SSI or not.

NT servers use "drive:path" denotations, unlike Unix.

So all that happened here (and what this thread is about) is that the default path I placed into the release version of perl-cookie.lib will work fine for ALL non-NT folks. And, it does. To perfection.

I forgot to mention in the docs that NT
folks need to modify the default path statement in perl-cookie.lib, that's all, Pilot, because '/' in NT doesn't work, obviously. I added in other small workarounds for NT folks (i.e. some environment variables are different) but in this case, I goofed and forgot to tell folks to change the default path if they run NT.

So, when NT folks modify the perl-cookie.lib to use NT's drive:path naming convention instead of the Unix which won't work for them, I'll fix their UserName and Password cookies to, they won't be logged out by accident, and I will be one happy code hacker!

Pilot - are you now in sync with me?

-Jim

------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

This message has been edited by hate98 on January 11, 2001 at 07:40 PM

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
+-----------------------------------------------------------------------+
IF YOU USE A WINDOWS NT/95/98/2000 OR ANY MICROSOFT SERVER READ THIS:
When specifying paths in login.cgi configuration, use standard notation
such as "c:pathfilename.ext"; in your variable definitions.
Also, modify the $Cookie_Path variable in perl-cookie.lib to include
your 'drive:path' instead of the default '/' which ONLY works for Unix.

For example, if you run Windows as your server, set the value like this:
$Cookie_Path = 'c:';

You may define alternative paths, but root path is required if you also
use the SSI hack. Like in Unix, for SSI and cookies to work together, this
is a technical requirement. If you fail to modify this variable, your
cookies will not work and the users will be logged out every time! ;-)
+-----------------------------------------------------------------------+


------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

This message has been edited by hate98 on January 11, 2001 at 07:45 PM

Joined: Mar 2000
Posts: 63
Member
Member
Offline
Joined: Mar 2000
Posts: 63
Your're gonna love me - the problem I referred to above (not working on NTwkstn) was due to a test machine having cookies disabled!!! Sorry. Sorry. Sorry.

I run IIS4/NTsrvr4, Activeperl v5.??? and can confirm that the script works when accessed via win95/NTw/NTs clients running NetscapeNav 4.08 and 4.7 with the $Cookie_Path = '/'; (i.e. default).

However, I changed the path c: and got an error message saying there was a problem on line 67, so changed it back to default and it works. The error given in IE5 when 'c:' is:

String found where operator expected at C:imcgi-binultimatebb/perl-cookie.lib line 63, near "$Secure_Cookie = '"
(Might be a runaway multi-line '' string starting on line 55)
(Missing semicolon on previous line?)
Number found where operator expected at C:imcgi-binultimatebb/perl-cookie.lib line 63, near "$Secure_Cookie = '0"
(Missing operator before 0?)
String found where operator expected at C:imcgi-binultimatebb/perl-cookie.lib line 67, near "@Cookie_Decode_Chars = ('"
(Might be a runaway multi-line '' string starting on line 63)
(Missing semicolon on previous line?)
Backslash found where operator expected at C:imcgi-binultimatebb/perl-cookie.lib line 67, near "@Cookie_Decode_Chars = ('"
(Missing operator before ?)
Backslash found where operator expected at C:imcgi-bin

Hope this helps...great hack BTW.

This message has been edited by spiffy on January 12, 2001 at 05:31 AM

Joined: Mar 2000
Posts: 63
Member
Member
Offline
Joined: Mar 2000
Posts: 63
I was wondering: I run a site (of which the BB is just a part, but all who have access are members of the BB) and currently control access via NT (Bacic Authentication - plain text) security. If I was to control access to the whole site via the login script, do you think it would be relatively secure?

[Edit: sorry, just ignore that, I've just read all the FAQs.]

Thanks.

This message has been edited by spiffy on January 12, 2001 at 06:33 AM

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Spiffy:

Thanks for the test, but sounds like when you put in c: you left off the trailing semi-colon which is a Perl requirement.

Or, try: $Cookie_Path = 'c:/';

Meaning, escape the slash so it reads it in Perl. Could be one of those two things. Please try and lemme know. Appreciate your help. Other users are having problems with cookies on NT servers, so I still think this is a problem.

------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

Joined: Sep 2000
Posts: 37
Member
Member
Offline
Joined: Sep 2000
Posts: 37
If I read it right, the UBB cookie scope does not matter for this hack.

You say that you don't touch the UBB cookies, could this mean that a user logins with your hack and then finds that although YOUR cookies are set, the UBB ones are blank (for whatever reason) and they have to enter their Username/password again (when posting for example)?

It would be nice for this hack to achieve SINGLE-SIGNON if at all possible so the user only has to enter their details once per session and all cookies are set up.

I just think that the user will wonder why he/she has to enter information for UBB purposes when they have already provided it for login.cgi purposes.

I like where this hack is going though, especially if the above concern is solved.

Good documentation - makes a change to see a hack well written up.

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Quote
quote:
Pilot, in terms of cookies used by UBB, the script SETS UserName and Password cookies after each login so those two fields are 100% guaranteed to be filled in when posting, etc. That's the "fix". The other cookies maintained by UBB, such as last visit time, preferences and so forth are RETREIVED by UBB after login first, then set to expire in a year. Those cookies were set by UBB in a previous session and last for one year. Logic dictates I cannot set cookies which first need to be retreived at that point, so I let UBB handle it normally and it works fine on it's own.

I cannot "fix" the others (last visit date most importantly) because of the simple fact they're retrieved after login by UBB, not set at that time, and that's required.

If I set them at logoff, major interference with UBB routines, plus not everyone logs off since it's the Internet and not a dialup connection, and UBB works fine for those other cookies for me and many others so why fix those if it aint broke! [Linked Image]

-Jim

------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

This message has been edited by hate98 on January 12, 2001 at 09:28 AM

Joined: Jan 2001
Posts: 2
Orc Offline
Junior Member
Junior Member
Offline
Joined: Jan 2001
Posts: 2
Question:

In the first part section 6 of login-setup.txt, some modifications to register_lib.pl are detailed.

I have UBB 5.47d without any hacks, and my register_lib.pl doesn't seem to match the one you are referring to.

login-setup instructs to replace the line:

with


3 times at lines around 23, 120 and 341

My register_lib.pl has the line:


6 times at lines 12, 61, 187, 360, 536, 721

Should I just ignore the fact that my version has the BypassCookie part?

Which 3 of the 6 instances should I replace, or should I replace all 6?

Thank you!

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
ORC: login.cgi is designed for 5.45x as the docs state so naturally things may be a little different from version to version. So change any instances and backup incase things get goofy, so you can restore later.

But I want to warn you, check the source and make sure that href refers to the UBB logo only. They refer to what happens if someone clicks on your logo. Just do not change any instances which are unrelated to the display of the logo. If unsure, do not touch those other lines.

------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

This message has been edited by hate98 on January 15, 2001 at 02:16 PM

Joined: Mar 2000
Posts: 63
Member
Member
Offline
Joined: Mar 2000
Posts: 63
Quote
quote:
That works just nicely...cheers.

Joined: Sep 2000
Posts: 37
Member
Member
Offline
Joined: Sep 2000
Posts: 37
OK so the UBB cookies are set, no matter if you have local or root scope set in UBB?

I am going to try the hack sooner or later but I want to know if I should change my cookie scope in UBB or leave it alone?

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Quote
quote:
Since my cookie library is external to UBB, which I stated in the docs and to you in previous conversation, that tells you any settings in the UBB CP have no affect on any cookies handled by my script and vice versa.

My script sets two UBB native cookies only at login, UserName and Password, and "fixes" any UBB problems which have to do with those two cookies only. No other UBB cookies have anything to do with my script. Thank you for your feedback.

-Jim



------------------
From: Jim Goldbloom
UBB Code Hacker
http://www.accessdeniedbbs.net/downloads for latest hacks

Joined: Jan 2001
Posts: 184
Member
Member
Offline
Joined: Jan 2001
Posts: 184
Ignore this reply. See reply further down on cookies and Windows servers. I think I finally got it licked.

This message has been edited by hate98 on January 15, 2001 at 02:17 PM

Page 1 of 2 1 2

Link Copied to Clipboard
Donate Today!
Donate via PayPal

Donate to UBBDev today to help aid in Operational, Server and Script Maintenance, and Development costs.

Please also see our parent organization VNC Web Services if you're in the need of a new UBB.threads Install or Upgrade, Site/Server Migrations, or Security and Coding Services.
Recommended Hosts
We have personally worked with and recommend the following Web Hosts:
Stable Host
bluehost
InterServer
Visit us on Facebook
Member Spotlight
isaac
isaac
California
Posts: 1,157
Joined: July 2001
Forum Statistics
Forums63
Topics37,573
Posts293,925
Members13,849
Most Online5,166
Sep 15th, 2019
Today's Statistics
Currently Online
Topics Created
Posts Made
Users Online
Birthdays
Top Posters
AllenAyres 21,079
JoshPet 10,369
LK 7,394
Lord Dexter 6,708
Gizmo 5,833
Greg Hard 4,625
Top Posters(30 Days)
Top Likes Received
isaac 82
Gizmo 20
Brett 7
WebGuy 2
Top Likes Received (30 Days)
None yet
The UBB.Developers Network (UBB.Dev/Threads.Dev) is ©2000-2024 VNC Web Services

 
Powered by UBB.threads™ PHP Forum Software 8.0.0
(Preview build 20221218)