#39264
01/06/2001 9:22 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
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
|
|
|
#39265
01/06/2001 9:55 PM
|
Joined: Aug 2000
Posts: 569
Member
|
Member
Joined: Aug 2000
Posts: 569 |
Thanks, installing now ------------------ I Disappear ? http://www.Metallifukinca.com
|
|
|
#39266
01/07/2001 8:50 AM
|
Joined: Oct 2000
Posts: 565
Member
|
Member
Joined: Oct 2000
Posts: 565 |
Awesome! thanks dude! ------------------ www.skinningworld.net
|
|
|
#39267
01/08/2001 11:25 AM
|
Joined: Mar 2000
Posts: 63
Member
|
Member
Joined: Mar 2000
Posts: 63 |
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
|
|
|
#39268
01/08/2001 11:40 AM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
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
|
|
|
#39269
01/08/2001 2:55 PM
|
Joined: Dec 2000
Posts: 4
Junior Member
|
Junior Member
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
|
|
|
#39270
01/08/2001 3:10 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
Joined: Jan 2001
Posts: 184 |
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
|
|
|
#39271
01/08/2001 9:29 PM
|
Joined: Nov 2000
Posts: 467
Code Monkey
|
Code Monkey
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
|
|
|
#39272
01/08/2001 10:40 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
Joined: Jan 2001
Posts: 184 |
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
|
|
|
#39273
01/08/2001 11:32 PM
|
Joined: Nov 2000
Posts: 467
Code Monkey
|
Code Monkey
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
|
|
|
#39274
01/08/2001 11:38 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
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: -jim ------------------ From: Jim Goldbloom UBB Code Hacker http://www.accessdeniedbbs.net/downloads for latest hacks
|
|
|
#39275
01/08/2001 11:50 PM
|
Joined: Nov 2000
Posts: 467
Code Monkey
|
Code Monkey
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
|
|
|
#39276
01/09/2001 12:03 AM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
Joined: Jan 2001
Posts: 184 |
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
|
|
|
#39277
01/10/2001 3:41 PM
|
Joined: Nov 2000
Posts: 51
Member
|
Member
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
|
|
|
#39278
01/10/2001 3:48 PM
|
Joined: Nov 2000
Posts: 51
Member
|
Member
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
|
|
|
#39279
01/10/2001 3:54 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
Joined: Jan 2001
Posts: 184 |
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
|
|
|
#39280
01/10/2001 4:04 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
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
|
|
|
#39281
01/11/2001 1:46 PM
|
Joined: Nov 2000
Posts: 51
Member
|
Member
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
|
|
|
#39282
01/11/2001 3:21 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
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
|
|
|
#39283
01/11/2001 3:27 PM
|
Joined: Mar 2000
Posts: 63
Member
|
Member
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.
|
|
|
#39284
01/11/2001 3:30 PM
|
Joined: Mar 2000
Posts: 63
Member
|
Member
Joined: Mar 2000
Posts: 63 |
...just looked at log, and says:
Forced Logout: [Did not login]
|
|
|
#39285
01/11/2001 3:42 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
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
|
|
|
#39286
01/11/2001 3:52 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
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
|
|
|
#39287
01/11/2001 3:53 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
Joined: Jan 2001
Posts: 184 |
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
|
|
|
#39288
01/11/2001 3:55 PM
|
Joined: Mar 2000
Posts: 63
Member
|
Member
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...
|
|
|
#39289
01/11/2001 4:05 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
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
|
|
|
#39290
01/11/2001 4:16 PM
|
Joined: Sep 2000
Posts: 37
Member
|
Member
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
|
|
|
#39291
01/11/2001 6:27 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
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
|
|
|
#39292
01/11/2001 7:10 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
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
|
|
|
#39293
01/12/2001 6:30 AM
|
Joined: Mar 2000
Posts: 63
Member
|
Member
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
|
|
|
#39294
01/12/2001 7:05 AM
|
Joined: Mar 2000
Posts: 63
Member
|
Member
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
|
|
|
#39295
01/12/2001 8:54 AM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
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
|
|
|
#39296
01/12/2001 9:47 AM
|
Joined: Sep 2000
Posts: 37
Member
|
Member
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.
|
|
|
#39297
01/12/2001 10:24 AM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
Joined: Jan 2001
Posts: 184 |
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
|
|
|
#39298
01/12/2001 11:41 AM
|
Joined: Jan 2001
Posts: 2
Junior Member
|
Junior Member
Joined: Jan 2001
Posts: 2 |
|
|
|
#39299
01/12/2001 12:03 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
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
|
|
|
#39300
01/12/2001 12:17 PM
|
Joined: Mar 2000
Posts: 63
Member
|
Member
Joined: Mar 2000
Posts: 63 |
That works just nicely...cheers.
|
|
|
#39301
01/12/2001 2:28 PM
|
Joined: Sep 2000
Posts: 37
Member
|
Member
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?
|
|
|
#39302
01/12/2001 3:15 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
Joined: Jan 2001
Posts: 184 |
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
|
|
|
#39303
01/12/2001 3:40 PM
|
Joined: Jan 2001
Posts: 184
Member
|
Member
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
|
|
|
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.
|
|
Posts: 70
Joined: January 2007
|
|
Forums63
Topics37,573
Posts293,925
Members13,849
|
Most Online5,166 Sep 15th, 2019
|
|
Currently Online
Topics Created
Posts Made
Users Online
Birthdays
|
|
|
|