No,
that happens because it is a quick and dirty hack. 
A bit cleaner version would be
elseif(!ereg("login\.php", $_SERVER['SCRIPT_FILENAME']))
Header("Location:".PUN_ROOT."login.php");instead of
else
set_default_user();401 2005-08-02 17:16
Re: nothing to see without login (7 replies, posted in PunBB 1.2 troubleshooting)
402 2005-08-02 15:49
Re: nothing to see without login (7 replies, posted in PunBB 1.2 troubleshooting)
A quick and dirty hack is:
Open include/functions.php
find line 104 (or so, I have some mods.. ) that says
else
set_default_user();instead of set_default_user you can write
Header("Location:".PUN_ROOT."login.php");403 2005-08-02 15:41
Re: Adding things to User List (14 replies, posted in PunBB 1.2 modifications, plugins and integrations)
Fairly easy:
1st open userlist.php
Go to line 150 where it says
<th class="tcr" scope="col"><?php echo $lang_common['Registered'] ?></th>After that, add
<th class="tcr" scope="col"><?php echo $lang_common['Last visit'] ?></th>Now, go to line 158:
$result = $db->query('SELECT u.id, u.username, u.title, u.num_posts, u.registered, g.g_id, g.g_user_title FROM '.$db->prefix.'users AS u LEFT JOIN '.$db->prefix.'groups AS g ON g.g_id=u.group_id WHERE u.id>1'.(!empty($where_sql) ? ' AND '.implode(' AND ', $where_sql) : '').' ORDER BY '.$sort_by.' '.$sort_dir.' LIMIT '.$start_from.', 50') or error('Unable to fetch user list', __FILE__, __LINE__, $db->error());and replace it with
$result = $db->query('SELECT u.id, u.username, u.title, u.num_posts, u.registered, u.last_visit, g.g_id, g.g_user_title FROM '.$db->prefix.'users AS u LEFT JOIN '.$db->prefix.'groups AS g ON g.g_id=u.group_id WHERE u.id>1'.(!empty($where_sql) ? ' AND '.implode(' AND ', $where_sql) : '').' ORDER BY '.$sort_by.' '.$sort_dir.' LIMIT '.$start_from.', 50') or error('Unable to fetch user list', __FILE__, __LINE__, $db->error());Finally, find in line 171
<td class="tcr"><?php echo format_time($user_data['registered'], true) ?></td>and after that, add
<td class="tcr"><?php echo format_time($user_data['last_visit'], true) ?></td>@InuKalriko:
You can do this with any field available in the users- or groups - table.
404 2005-07-30 11:05
Re: Hosting: Shared vs Virtual (13 replies, posted in General discussion)
hcgtv wrote:
Tobi, my sites on Site5.com are just popping, so if there is a performance hit, I haven't seen it yet.
There is a performance hit, that much is sure.
If you feel it or not is another story and depends on the server and the number of users you're having.
So if you get along fine don't worry.
Only if performance is dropping then PHP running as cgi is one suspect (after bad programming and too many users connecting .. )
405 2005-07-29 20:30
Re: Hosting: Shared vs Virtual (13 replies, posted in General discussion)
afarber wrote:
Since you're using Debian: check out OpenBSD.
I have my server running on FreeBSD and it's really a good thing to do I guess.
BSD is hell when you want to have an X/Desktop-system but for a server it's just a bit more work than linux.
The main adavantage is the same that Linux has over Windows:
Since there are not so many BSD servers out there there are not as many discovered and exploited security holes. It's just not as interesting.
plus it is really stable, never had a kernel panic or such, and I do bad things to the poor little machine sometimes....
406 2005-07-29 20:25
Re: Hosting: Shared vs Virtual (13 replies, posted in General discussion)
sleddog wrote:
Just a FYI... site5.com runs PHP as CGI (phpsuexec) on their servers. Which means that you can chmod 600 all your PHP files (especially config files) and you're neighbours can't access them.
Which also means quite a payload in performance.
Oh well, I guess you can't have one without the other.
Second, I think there is some confusion between write and read permissions.
What afarber means that other people sharing the server can see your code.
Doesn't sound like a problem unless they find your precious config.php with the DB access data...
Only way around that is to have all accounts jailed.
It's understood that nobody except for you should be able to write toyour files ...;)
407 2005-07-29 09:30
Re: Hosting: Shared vs Virtual (13 replies, posted in General discussion)
I guess you make the best choice for you then.
I just moved all my accounts from my dirt-cheap-but-no-real-service Rootserver because I was tired of having to be paranoid 24/7. Then yesterday, I had *just* finished, the HD crashed for the 3rd time in 2 years. Luky me
I just want to say:
Unless you are a unix god or unless you don't really mind reinstalling your complete once in a while for various reasons - stay away from root servers.
Yes, they are cheap, yes, they give you incredible amounts of free traffic - but you pay in working hours and nerves...
But even a good VPS means that you have to e extremely careful with your setup, keep *everything* current and so on.
On more thing to consider:
Most hosters offer backup which is normally an incremental backup, one version only.
So if anybody manages to install a rootkit on your machine, be it virtual or not, and you find out after 2 weeks you have no clean backup to install.
At least yuo should keep versions for 2-4 weeks on your HD. A HD crash AND a rootkit install is possible but not s likely..
408 2005-07-27 17:42
Re: Analyzing logfiles (2 replies, posted in General discussion)
AWStats is not more or less vulnerable than any other app if you keep it up to date and disable the big neonsigns saying "HACK ME" (online updating f.e.).
I think it can be installed locally as well (in you own cgi-bin then) if you have read access to your raw log it should be no problem.
I used webalize for a long time but stopped immediately when I discovered AwStats. No comparison but the second choice if you can not run AwStats at all...
Ah, forgot:
If you protect your AwStats with a .htaccess file it should be safe enough anyway.
Give it a try.
409 2005-07-27 10:05
Re: Hosting: Shared vs Virtual (13 replies, posted in General discussion)
I am running two servers that are my own plus some shared space.
With that I never had any trouble.
I think you should consider the following:
SHARED HOSTING
YES if you have static content mostly
YES if your provider gives you all the features you want (PHP, MysQl, Python, Imagemagick, whatever)
YES if he's flexible enough to install them for you if they are not here (mostly smaller companies do that)
NO if you have REALLY hungry apps or you need lots of space/bandwidth
VPS:
It is really a lot ike shared hosting in that you totally depend on how many people share a machine.
with the exceptiin that you have control over the software running
ROOT SERVER:
If you are a control freak this is for you.
But You should really think about security.
Are you capable and willing to spend a lot of time to keep your system up to date and protect it against hacker kiddies?
Do you want to mess with complicated backup strategies to have everything there when yu need it?
I'm talking out of experience here.
I am a control freak and I pay for it.. 
Moneywise:
Think about it.
You can get a good shared hosting pack for abround 8 EUR/month
For 19 you can get a VPS
For less than 40 you get a root server.
It only matters what you do there and if it's worth it.
With some google ads you can pay even the root server, that should be no limitation.
And don't think too much about CPU power.
We have lots of apps running, some of them are very busy, we have also a number of quite frequented sites up, and all this now runs on a machine that is now 6 years old.
Better invest in a RAID system and a considerable amount of memory than into a super duper turbo CPU.
Your apps won't need it as much.
Sure they will run a bit faster, bt you won't really need it.
From my experience a good debugging session in your apps gives you more speed than a brand new dual processor
410 2005-07-26 20:17
Re: MS Betas (27 replies, posted in General discussion)
Jansson wrote:
And, can somebody tell me what must-have features Longhorn have?
A rocksolid DRM.
Isn't i a great feeling that it will be asbolutely impossible for you to accidentally watch a movie that might be totally illegal for you to watch, thus preventing you from peeling potatoes in some shithole prison close to the north pole for the rest of your young life?
411 2005-07-26 08:10
Re: Bans don't affect extern.php (6 replies, posted in PunBB 1.2 bug reports)
If I understood it right the concept behind extern.php is to spread the word outside of your forum, and of course yu cannot check users there.
I think you just shouldn't show things through extern.php that not everybody should see....
412 2005-07-24 10:00
Re: Query Loops (6 replies, posted in Programming)
Doesn't make sense to me.
The result of
$sql=$db->query("SELECT blah FROM blah WHERE blah='blah' DESC LIMIT 10");will be an array called $sql holding another array with single values like
0=>'banana',1=>'apple',2=>'peach',3=>'dogshit'
It will not output an array with proper sql statements to use in your while ($db->query($sql)) loop.
And if it does shouldn't the result of
$db->get_num_queries() be 11 ? 
413 2005-07-23 14:47
Re: Is it possible to use punBB with cookies disabled? (9 replies, posted in Feature requests)
afarber wrote:
What I'm trying to say is that cookies, URL and hidden fields are actually same
for the ticket methods. With the exception that some users disable the former.
- And the exception that you can send a sessionID URL by email but not a cookie.
- And that SID-urls are really not liked by google
I don't want to start a religious war here, I just want to say I like punBB using cookies.
If my users do not trust me enough to accept cookies from my site they can stay out. No prob
Anyway, although it is some work to change punBB to use php sessions but it's no science, so why not?
414 2005-07-23 13:17
Re: I've been hacked (10 replies, posted in PunBB 1.2 troubleshooting)
I think it is the basic install:
<IfModule mod_security.c>
SecChrootDir /secure/secapache
# Turn the filtering engine On or Off
SecFilterEngine On
# Make sure that URL encoding is valid
SecFilterCheckURLEncoding On
# Unicode encoding check
SecFilterCheckUnicodeEncoding Off
# Only allow bytes from this range
SecFilterForceByteRange 0 255
# Only log suspicious requests
SecAuditEngine RelevantOnly
# The name of the audit log file
SecAuditLog logs/audit_log
# Debug level set to a minimum
SecFilterDebugLog logs/modsec_debug_log
SecFilterDebugLevel 0
# Should mod_security inspect POST payloads
SecFilterScanPOST On
# By default log and deny suspicious requests
# with HTTP status 500
SecFilterDefaultAction "deny,log,status:500"
SecFilterSelective ARG_highlight %27
SecFilterSelective ARG_highlight %2527
SecFilter "visualcoders\.net/spy\.gif\?\&cmd"
SecFilter "wget"
</IfModule>I added the "wget" directive
wget is the program that most hackers use to load their stuff after the attack.
Since this string will not occur on my sites I blocked it. You don't have to but it will make you sleep better.
Take care to have SecFilterScanPOST set to "On" so you filter POST requests as well!
If you want to make your own rules there is even a rule generator .
The trickiest part is the
" SecChrootDir /secure"
This works a bit like a BSD jail for apache.
If you are using a Linux machine read on:
That means all commands working through apache believe the server root is under /secure/secapache
So, if you do not place a copy of Perl, fetch, wget, htget or whatever else these psychos use under that directory they cannot execute their commands.
The SecChrootDir does not have to be the directory where your apache resides. Can be anywhere.
But:!
To have php working as usual you will have to put *some* binaries there:
If you work with system() or exec() or the likes you need to copy
/bin/ls
/bin/sh
to
/secure/bin/If you want to use the php mail() function you have to install mini_sendmail
And enter this into your php.ini in the mailer section (where you normally have /usr/sbin/sendmail or the likes):
/usr/sbin/mini_sendmail -t -fyourname@yourdomain.comThen copy these libraries:
/lib/libnss_dns.so.2 --> /secure/lib/libnss_dns.so.2
/lib/libnss_files.so.2 --> /secure/lib/libnss_files.so.2
/lib/libresolv.so.2 --> /secure/lib/libnss_files.so.2
/etc/resolv.conf --> /secure/etc/resolv.confIf you want to use MySQL you have to make the socket readable by php:
vi /etc/my.cf
[mysqld]
socket=/secure/tmp/mysql.sock
[client]
socket=/secure/tmp/mysql.sockThat should be it as far as I remember... the SecChroot story is a bit difficult I admit but it gives you enough security to not be afraid of the psycho kiddies anymore.
All you have to do now is make a backup of everything under /secure because this is all they can destroy even if they make it through your filters.
Note:
Yes, it is possible to escape this jail. However, it is anything else than trivial and I don't know of a copy/paste exploit that can do it. It requires handwork which means you must be a valuable target to a hacker to even try.
I hope this helps
415 2005-07-23 09:49
Re: Is it possible to use punBB with cookies disabled? (9 replies, posted in Feature requests)
If you have the session ID in a cookie then somebody must hijack or otherwise steal the cookie.
Possible but technically more complex.
If you have the session ID in a string then you have the key to your site sitting in every url cache in any browser in any internet cafe where your users decided to visit your board.
In theory again but - any stupid can do it so it is likely that any stupid will do it.
Plus, technically challenged users will always copy the session ID when they send links to friends. They do, yes, I know this out of bad experience...sure you wil have a timeout but still you have to let the SID live for a while, right?
Plus, as connor said, searchengines do not find these session strings very attractive.
416 2005-07-23 09:06
Re: I've been hacked (10 replies, posted in PunBB 1.2 troubleshooting)
Frank H wrote:
(myself, I'm goign to take a look at that mod_security for apache today ... looked promising at removing bad stuff
It is.
And it keeps the attempts in a log file. Very interesting from a forensic point of view...
I haven't had any trouble since.
I can give you my basic rules for the setup if you want.
417 2005-07-22 19:47
Re: Is it possible to use punBB with cookies disabled? (9 replies, posted in Feature requests)
Theoretically you could.
It needs heavy modification of the source though.
Instead of setting and modifying a cookie you must set and modify a session.
Sounds easy but it affects tons of pages.
And I wouldn't want it, this URL session handling is insecure like nothing else.
I mean anybody could find a URl with a valid session identifier somewhere...
418 2005-07-22 16:09
Re: Last visit (2 replies, posted in PunBB 1.2 modifications, plugins and integrations)
Well, you could do something like this (untested)
<?
$now = strtotime(date("Y-m-d")." 00:00:00");
$lap = ($now - $user_data['last_visit']);
$days_passed = ceil($lap / 86400);
if($days_passed == 0) echo "Today";
elseif($days_passed == 1) echo "Yesterday";
else echo $days_passed . " days ago";
?>However, this looks bad when somebody hasn't logged in for years and it doesn't reflect the fact that you shouldn't hard code things like "Today" but instead use the lang files.
But I guess you got the direction
419 2005-07-22 15:48
Re: MySQL (3 replies, posted in PunBB 1.2 troubleshooting)
Well,
do you have
a) your own server or
b) some webspace pn a shared machine?
If a) then you should know how to do it
Go to the php source directory
>./configure (with all the options you want, see the php manual)
> make
> make install
If you do configure --with-apxs then you just restart the apache.
Best is though you take a look at te php website, they have an excellent documentation.
If b)
then your provider should do the updating.
420 2005-07-22 12:39
Re: Including extern.php (4 replies, posted in PunBB 1.2 troubleshooting)
It says "temporaray failure in name resolution", so that probably means that it will work again sooner or later
421 2005-07-22 12:37
Re: MySQL (3 replies, posted in PunBB 1.2 troubleshooting)
That usually happens when you upgrade myql.
version 4.1 uses a different Paswword encryption method.
As long as you do not touch the old password entries everything will function, but once you enter a new one the old
mysql clients can not use it.
You'll have to recompile php with the new mysql libs or mysqli.
422 2005-07-21 08:28
Re: Making PunBB More Local Customizable . . . (21 replies, posted in PunBB 1.2 discussion)
Rickard wrote:
I'm just afraid adding a big ol' template system would make PunBB less of what it is now and more of what every other bulletin board is. Remember, feature creep is our biggest enemy.
You are absolutely right, and that's why I finally chose it. The more features you have the more likely it gets that you will have security holes somewehere. And it's more difficult to handle as well.
However, changing the way punBB outputs pages does not mean adding features.
It's just the way html and php code is handled.
I do not even know if it would/could make punBB faster but I do know it makes the whole thing more readable.
What is wrong to go with the bunch in this (and only in this) respect?
In my opinion PunBB can still be the easiest and fastest system.
Jansson wrote:
I love it that you can just download PunBB, put it on your server, run the install script and get it running in seconds.
You could still do that. Templates do not mean that it makes the whole thing more difficult to install.
Jansson wrote:
If you need extreme functionality, there is options. The price you pay is slower development (PunBB only have one developer and still bugs are fixed relly fast) and a slower software.
I think there is a mix up between the way the board is spit out to the user and the wealth of features it should have.
For me, this discussion is only about the structure of the code. Not more.
And I believe that with a template system there would be more people who could help developing the whole thing.
As for smarty:
I think this one is a bit too much.
It has its own syntax and is not always easy to understand for the beginner.
Plus, with all its tags it puts way too much programming in the html templates.
What makes a template system so strong for me is the distinction between logic and markup and in this respect smarty doesn't really make it.
423 2005-07-20 20:08
Re: Making PunBB More Local Customizable . . . (21 replies, posted in PunBB 1.2 discussion)
Paul wrote:
Disadvantages (cont.)
5. PunBB looses some of its distinctiveness
Don't think so.... I truly believe you can do something easy and professional and that will still distinct punBB from all those really badly writen boards out there, template driven or not.
Paul wrote:
6. Loss of quality controls. There will be some truly awful templates produced.
That's for sure
But you don't want to see some of the styles I made...
Paul wrote:
7. I will have to rewrite all the sodding markup - again.
8. Rickard will have to rewrite all the files - again.
Well, that sounds like your very personal disadvantage I admit.
For the rest of us I still think it would be a benefit.
424 2005-07-20 17:13
Re: Making PunBB More Local Customizable . . . (21 replies, posted in PunBB 1.2 discussion)
hcgtv wrote:
I like the idea of abstracting out the templates and styles and I think it can be done without relying on Smarty or any other outside mechanism.
Sure enough.
Smarty is a heavy weight, I think it would be possible to incorporate something in to punBB handling the template parsing.
That also avoids the dependancy on third party projects.
425 2005-07-20 16:50
Re: Making PunBB More Local Customizable . . . (21 replies, posted in PunBB 1.2 discussion)
Paul wrote:
Advantages:
.........................
8. Marketing. For some reason end users seem to like the idea of skinning via templates probably because it's what everyone else does.
Actually it is the easiest way of skinning, maybe that's why everybody else does it.
Sure the whole thing looks more "grown up" if you separate code from html, but on the other hand that's waht it really is then.
Paul wrote:
Disadvantages:
1. More complexity so a longer development cycle
I don't believe so.
I work for 6 years with a (self made) template engine now and once you know the basic tags it is so much faster to develop... No need to sink knee deep into html tags just because you have to apply a security fix, no need to touch the code just because you want to make things look totally different, and most of all, it is much, much easier to develop extensions if code is code and html is html.
Paul wrote:
2. Harder to maintain. It's more work maintaining a dozen templates than it is maintaining a dozen stylesheets in those cases where new versions also include template changes.
But easier to maintain if you combine these two.
There can be template changes and style changes, right?
Paul wrote:
3. Possible integration problems where a different templating system is already in use.
I've never heard of incompatibilities with two template engines. It might just get confusing.
Paul wrote:
4. Can't think of anymore which is interesting in itself.
Now, this is a disadvantage
Rickard wrote:
The big question is whether we want to take PunBB to the "next level". Adding Smarty support might increase performance, but it would also increase the complexity.
Do you really think so?
Sure, it looks a bit more complicated at first but then again, isn't upgrading/modding much easier with a template system?
I surely would love to follow punBB onto that level and I would help reaching it if wanted.
I am used to projects where code and html are always stictly separated and it's so mauch easier to maintain...
I see your point though, for the absolute newbie it might look a bit heavy. But is a full blown BB system the best project to start with for a complete newbie anyway?