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

Thanks, installing now

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

Awesome! thanks dude!

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

First: excellent hack - very well done

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:


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

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

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

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

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

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

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

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:


-jim



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

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

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.)

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

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

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

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

see response below if running the script on NT

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

>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

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

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.

...just looked at log, and says:

Forced Logout: [Did not login]

see the response below about NT

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

workin on it...wait for next response please

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

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

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...

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

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

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

+-----------------------------------------------------------------------+
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

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

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

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

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.

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!

-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

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!

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

That works just nicely...cheers.

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?

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

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

OK I have installed this hack now and have these comments.

It's very good code in general. Thanks!

1 - Be great if the last login date was stored in the member profile (in a spare field), then I could identify inactive users and remove them (also a hack to automate that would be handy).

2 - It would be nice if the "processing.." forwarding pages picked up the local UBB color settings (as most sites have different color schemes). I had to edit the CGI here.

3 - If you could supply a sample login form inside a table to align the fields neatly (I know you supply your HTML but that contains a lot of other stuff). Most people probably just want to include a login box on their existing home page (a bit like the Email login box on UBBDEV).

4 - Need to remind people to adjust other hyperlinks that they mave have to the UBB scripts for "registration" and "lost password" to use your CGI instead - or these UBB links will just bounce users out.

I'm not using SSI, as I don't need total security - just trying to get normal users to register first, before viewing.

Cheers

This message has been edited by Pilot on January 13, 2001 at 12:59 PM

>1 - Be great if the last login date was >stored in the member profile (in a spare >field), then I could identify inactive >users and remove them (also a hack to >automate that would be handy).

Pilot, that's a request for the UBB folks, not me.

>2 - It would be nice if the "processing.." >forwarding pages picked up the local UBB >color settings (as most sites have >different color schemes). I had to edit the >CGI here.

Sure, but others told me it should remain as is because the screens, being different, draw attention to the them and also they only display briefly. But I see your point and shall consider it for next release.

>3 - If you could supply a sample login form > inside a table to align the fields neatly

HTML is up to the user. Do as you see fit and the example is more for the forms tags and not the layout. You missed the point of the example page if this bothers you, the example page is to remind folks to create a login page, what to include on it, and also how to call the script in the HTML. The rest is window dressing. So if you're bugged by this minor problem, send me a file you feel should be included in the docs. My time is better spent on improving the script.

>4 - Need to remind people to adjust other >hyperlinks that they mave have to the UBB >scripts for "registration" and "lost >password" to use your CGI instead - or >these UBB links will just bounce users out.

You couldn't be more wrong. Don't take offense at this, please. The login script means ALL users login from a central starting point so the authorized cookie gets created so no bouncing. This is emphasized in the documentation as is this concept. I even went so far in the docs to stress folks should promot the login page URL, inform users to bookmark the new page, and that the login page is THE most important part. Obviously in your mind you completely missed this basic and crucial concept of my hack.

Pilot, I've listened to you, and addressed your concerns. If you have any other issues, please send them privately. I tremendously appreciate your feedback, as I do from all UBB webmasters, and appreciate you using the hack and saying nice things about it. Thanks so very much, and now I will move on to other folks issues.

Take care, Pilot. :-)



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

Anyway to clarify one point. I had links to register and lost password on the SAME page as the login fields (my home page) - so they didn't work until they were changed. Maybe I did something wrong - but that is what happened to me and may happen to others.

I post here, on this public UBBDEV site to share my experiences with the other members and don't expect a personal reply from the author of the hacks. Free feel to concentrate on the more important tasks that you have.

I have updated the docs and perl-cookie.lib for Windows users to assist them in setup.

For latest version:
http://www.accessdeniedbbs.net/downloads

Thanks to all the UBB users who helped me work out the kinks for Windows users in 3.0!

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

This message has been edited by hate98 on January 14, 2001 at 10:16 AM

wanted: beta testers for 4.x

email [email protected]

This message has been edited by hate98 on January 14, 2001 at 10:26 AM

hate98,

I'm running the UBB on Unix btw...

AgentX

H, I've tested the changes you made re: Win32 servers and I'll have to go back on what I said about changing the cookiepath.

Only '/'; works for me, anything else 'c:/'; or 'c:\'; DOES NOT WORK. I'd got this a bit wrong recently, sorry about that, but I'm now quite sure.

BTW I do have a c: drive.

Thanks spiffy, I've had others help out with this and I've updated my docs for Windows folks. Issue is now resolved. Take care.

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

Can you explain how to make the cookie expire after a certain time period instead of after the browser session? I would like to make it so a person would have to login every 24 hours, but in your documentation of the cookie script you only show how to make a fixed expiration date/time.

Thanks for the great script.

------------------
Mike
------------------
Visit STCC: stcchat.com

In the next beta I am going to add an option for the cookie expiration and some traps that will force a logout. This will be a new config option in login.cgi and I'll allow you to decide how users are to be forced logged out in terms of cookie expiration.

However, with that said, can you please explain why you want to ensure users cannot remain online to your web site for >24hrs? I'd just like to hear what you have to say as this will help me construct the beta options accordingly.

-jim

------------------
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:19 PM

Mainly because I have installed the little line of script checking for their cookie, so as long as they have logged in, in the last day, they will be able to post and stuff without re-entering data, but the board should not be viewable to those that haven't.

A lot of my board's members are really pissed that they have to spend 10 seconds typing in data every time they come to the page.

------------------
Mike
------------------
Visit STCC: stcchat.com

I know they get pissed, but I want everyone reading this thread to think about something...

The login concept is to ensure ONLY authorized users can gain access, in addition to solving UBB missing cookie problems with UserName and Password.

With the current concept, a user logs in once, can leave their browser open for all eternity and they will not have to login. Unless, of course, they either logout or close browser session.

I could add in a javascript cookie detect routine in the login page which would allow users have either their username and password already filled out so all they need to do is click on the submit button. Or, if cookies detected, simply take them to your $welcome page defined in the config.

BUT --- and folks, pay attention to this --- what if someone else comes by and uses the computer? Or what if a child gets into an adult UBB because the cookies still exist? Or some folks in a work environment where everyone shares a lan and PC's are all over the room with Internet access? One employee could "use the login" of another employee who stepped away from his desk more easily than before.

You see, a login being required is a GOOD thing, and my original concept of additional security does mean users will and should type in their username/password at each visit.

This is how the old dialup BBS's worked, and how high end secured web sites work. The "convenience" features such as bypassing login to avoid "pissed off users having to type in something which takes 10 seconds" are really dangerous at their core.

I'd like to get some opinions on this, what do you think is the best strategy? I personally think those extra 10 seconds provides you, the webmaster, and unknowingly the user, with some peace of mind that only they are using their account.

So, bells and whistles can be a bad thing.

Thoughts, comments?




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

I realize doing something like this would undermine the security aspect of the login somewhat, however, people with IE5 already have their usernames filled in most of the time and sometimes passwords. I installed this hack primarily because a good chunk of our userbase doesn't show up in the Who's online hack, which this remedies.

Adding an optional javascript code to add to the login page to remember username/password would be good. Or to simply have it bypass the welcome screen entirely. I still think my idea of having the login expire after a set ammount of time provides improved UBB security, while being more convienient for users that are against having to login at all. That way, for a limited time their login info would be "insecure" but it would be secure after the set ammount of time.

------------------
Mike
------------------
Visit STCC: stcchat.com

Yes, that's my thinking also. The reason your who's online script works better (and also why username/password are filled in properly each time when posting) is because the login page sets cookies. It's pretty easy to retreive when you know they've just been set!

For now I think the best plan of attack for the upcoming beta is to allow the option of a UBB webmaster to set a time limit on the life of the "authorized" cookie. So your request will be granted and expect it in the next public release in one form or another. Thanks for the excellent suggestion.

I strongly feel the login fields should be blank upon each visit to the login page for the obvious security implications. You seem to agree and thank you for your opinions.

Other opinions encouraged, please speak up, I will check this thread occasionally.

On a side note: If I was designing UBB, I would have used cookies to store certain things, but other things such as list visit time, last post, preferences and private forum access are better stored in the member database. I had folks ask me to design that into the UBB and my script, but such integration would make my hack no longer an "Addon" hack, but instead a new UBB which would undoubtedly BREAK any other UBB hack which accesses the member files. Plus, I'd have to maintain any files if I opted to store such data externally. Bottom line? It's easier for us to suggest this type of behavior to the UBB folks and not me!

-Jim



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

The HTML code attribute you need to add to thetag is just:that way, no matter what a person's autocomplete settings are, they can't use autocomplete on it.

------------------
Mike
------------------
Visit STCC: stcchat.com

This message has been edited by mmnatas on January 15, 2001 at 03:21 PM

Not necessary. I prefer to allow UBB webmasters to design their own login page and add whatever bells and whistles they want, as that's external to my script. Besides, nothing wrong with autocomplete because the password field is still **** and that's a time saving feature which I feel is nice to have and offers benefits. In other words, I'm all for security, but I'm not saying logging into a UBB should be like breaking into a bank's ATM machine either! heheh

------------------
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 03:22 PM

Another thing that could be improved on is the logging. Instead of just deleting the log, could you either delete off the oldest entries, or have it save back so many hours/days?

------------------
Mike
------------------
Visit STCC: stcchat.com

I've decided againt making a super fancy log which reads/writes and does archiving and more intelligent decision making. Why? The script needs to run very fast behind the scenes and it's called quite often. I opted to use a simple append write function (with file locking) to speed up things and it really, really makes a difference.

You'll need to manage the logs on your own via server side scripting (i.e. cron jobs which move the logs to an archive directory every Xth day of the month for example) to avoid nasty server performance hits. That's why I put in the logging disable commands also.

Less is more in my opinon.

-Jim


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

Jim I do find the suggestion by mmnatas very usefull. I wanted to install this hack but didn't in anticipation of what he is seeing.
The security concept should be that it is upto the user whether they want to take the extra 10 seconds and type the password or whether they want it pre-filled.
This is a very neat hack specially for those who have Who's online installed.

Jim if you are working on a newer verion with these bells and whistles it wouldn't be a bad idea to wait few more days and make it UBB6 compatible

I'm all for that! :-)

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

Hi! i made a little change to this hack to make it look like your board when processing missing login, invalid login, etc...

find:

require "UltBB.setup";
require "ubb_library.pl";
require "Date.pl";
require "perl-cookie.lib"; # special cookie library for perl - IMPORTANT
};

and add after:

#adjust bgcolor variables
if ($BGColor ne ""){
$BGColor = qq(bgcolor="$BGColor");
}
if ($AltColumnColor1 ne ""){
$AltColumnColor1 = qq(bgcolor="$AltColumnColor1");
}
if ($AltColumnColor2 ne ""){
$AltColumnColor2 = qq(bgcolor="$AltColumnColor2");
}
if ($CategoryStripColor ne ""){
$CategoryStripColor = qq(bgcolor="$CategoryStripColor");
}
if ($TableColorStrip ne ""){
$TableColorStrip = qq(bgcolor="$TableColorStrip");
}
if ($PageBackground ne ""){
$PageBackground = qq(background="$NonCGIURL/$PageBackground");
}

find:



and replace with:



find and remove: (right under the )

color="#ffffce"

do it twice

that's all...

what do you think?

this is my first "hack" in a hack...

------------------
TyRaN = tyranausaure



This message has been edited by TyRaN on January 18, 2001 at 02:34 AM

Excellent. I will implement a form of that in the next release. I am waiting for UBB6 to come out and will release mine after that.

-Jim

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

thanks... i apraciate the compliment...

------------------
TyRaN = tyranausaure

Any new developments with beta 4?

------------------
Mike
------------------
Visit STCC: stcchat.com

No beta 4 until UBB6 out which is end of this month according to the InfoPOP site. I am on hold until then.

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

why your going to make me cry

------------------

First, nice hack.... great instructions!!! A++++[br]but how can I stop the pages from breaking out of my frames... I have tried multiple attempts at editing the login.cgi but to no avail... Please anyone help...

------------------

Are you referring to the SSI frames hack?

If not, the script does not set any targets so by default pages will load in _SELF which means the same page from which the script was called. I run frames on my page and everything works great. It's a fatal mistake to use crazy target names and not keep track of 'em. That has nothing to do with the script. Or, maybe you use a javascript routine which forces a breakout of the frames? Remove it, if so, but that's not performed in login.cgi, rather that's in your login page HTML (i.e. the demo login page included in the docs).

If you are referring to the SSI hack where a user visits a forum topic and gets redirected back in a frames setup, then you simply did not cut/paste the correct URL into the config of login.cgi. I use it on my site, and trust me, it works fine. No bug reports from anyone on this aspect of the script.

Hope this reply addresses your issue. If not, I need the URL of your site and an explanation of what I need to do to create the problem when I visit.

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

thanks for replying so quickly... The base target in the sample was set to _top, when it should of been to main_scrren.... thanks for kicking the cob webs out... now I know it's time to get to bed...

------------------

I use basic authentication on my site, is there any way to get the username and password from an NT session and pass it to the login script, thus bypassing the need to enter details twice?

Sorry, the script was not designed to be used in conjunction with other auth methods, but rather to replace any existing method.

I suggest you do not use the script.


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

Thanks, Jim. I'll use the script because it's really impressive, I'll just implement the SSI part.

Another query please: I have a chat room on my site, is there a way I could use the cookie information from your login script to integrate into the chat script which requires a username/password to be inputtd before accessing, i.e. getting u/p from the cookie and filling in the appropriate text boxes?

Thanks, again.

On my web site I have user chat in the form of an applet. Instead of using HTML to display the applet and so forth, I made a perl script instead. If you know Perl, then I do not have to explain, you'll know what I mean and how to integrated variables into HTML (that's for advanced users only.)

The other way to do this is to write a javascript routine which loads cookies and fills in the username field automatically.

None of this has anything to do specifically with the login script, please note.

Visit my BBS http://www.accessdeniedbbs.net and go to my chat function and you'll see how I did it. I used the Perl method.

-jim

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

LOGIN.CGI - Version 3.5 [Public Release]
Supports versions 5.xx of UBB Licensed ONLY
By Jim Goldbloom [email protected]

Release date: 02/02/01 3pm

This is my final release for 5.xx series of UBB.
A new beta for UBB6 users will be available in a few weeks.

What is LOGIN.CGI?

So you're thinking why not just use .htaccess and be done with it? HA! I say, HA HA HA! ;-)

This version supports support for UBB styles (colors/fonts/etc.) plus a nifty new option to ban users who do not have posting enabled in their profile, if you wish. Other cosmetic fixes and it's an EXTREMELY stable version. I also updated the docs and perl-cookie.lib to help Windows users. This is a complete front end to tighten security on your UBB and allow a customized login screen complete with guest login support (optional), SSI redirects of forum topic pages requiring login first, IP ban checking, invalid/missing/illegal logins, and fixes problems with a few cookies. This is a powerful front end and I am sure you'll enjoy, it's highly customized and even includes custom redirect option you can use as you see fit.

Full features listing in this version:

* authenticates username/pass with UBB member files
* catches/logs ALL invalid/missing/illegal logins
* full support for IP ban list in CP
* Optionally force logout users who do NOT have
posting capability enabled but are registered.
* 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
* colors and fonts are pulled from UBB styles
settings so clean, integrated interface for
any HTML generated by the script.

See it in action: http://www.accessdeniedbbs.net
(support forum in place on the BBS) - UBB6 with beta login script

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

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

DO NOT RESPOND TO THIS EMAIL
SEE THE NEW THREAD I POSTED.
THANK YOU.

Moderator - please kill this thread.