Add new comment
Joomla has served me nicely for quite a while now. But over time I have become frustrated with the lack of "native" comments and forums and the various hacks to get comments/forums working nicely. I've had some success with SMF, but the pain one needs to endure to keep the user database, session cookies and passwords getting lost by themselves finally got to me. The one thing which I still believe is better are the Joomla templates supplied by Drupal templates still seems to be lacking. Thankfully, HTML & CSS isn't that hard anyway (not that I am claiming to be an expert), so with some external inspiration from other websites it is still possible to build something half-decent looking.
In addition to my homepage at kjeldahl.net, I also run a site dealing with investing and trading resources named keelix.com. On that site I actually hook into the CMS system's user authentication and session systems to allow people access to various resources. For simple web-stuff, I'm mostly a perl person, so hooking into foreign authentication and session systems is a bit more challenging than "including" some PHP snippets in PHP code/templates.
Over the last year, the SMF forums have been gradually poisoned by spam that registers as valid users and post their spam in the different forums. Now it may be that SMF and/or Joomla have some nice captcha modules ready to go already, but bearing in mind the troubles I've had with integrating foreign forums, I decided to see if something else could make my life simpler. From what I have seen so far, Drupal seems to be it. It offers commenting, simple forums and captcha modules more or less out of the box. Well, the captcha modules had to be installed separately, but differently from what I experienced with Joomla, the first captcha module I found through drupal.org worked without any trouble. So I decided to switch from Joomla to Drupal.
One of the system on keelix.com is a "backtester", basically loads data for most public US-based companies almost 10 years back with some code which allow testing trading strategies such as "is it profitable to buy companies with a low price/earnings ratio" and "does price momentum with a low book/value work"? If this is greek to you, don't worry, you do not have to know or care about trading to understand what I am trying to do. The point is that running the backtester is very disk and CPU intensive, so I want to know a little bit about who is using it. Since one single backtest can hog the server for anything from 2-200 minutes it is also very important to implement a queuing system to avoid a single user hogging the machine more or less forever by submitting multiple large jobs.
The way the system now works running under Joomla, is basically verifying the state of the SMF cookie that the Joomla/SMF integration is using. If the user is correctly logged in, allow him access to the backtester. If not, tell him to log in first and come back. This will be the same strategy I will be using for Drupal.
Drupal sessions are stored in a table named "sessions". An entry in the table when the Drupal administrator is logged in typically look like this:
=# select * from sessions; uid | sid | hostname | timestamp | cache | session -----+----------------------------------+---------------+------------+-------+--------- 1 | 8289f0651b17de28932f4a9xxxxxxxxx | 84.49.241.217 | 1193903244 | 0 |
After logging out or before logging in, each user is given a session id (sid) which is stored in the sessions table with uid 0. After a successful login, the uid is changed to the actual uid of user who logged in.
So for any "external" program (external to PHP/Drupal that is), it should be sufficient to:
- Look for the Drupal session cookie (the name of it is usually auto-generated when installing Drupal)
- If found, look it up in the sessions table. Search the sessions table where sid equals the cookie value.
- If row is found with the correct sid and uid is anything but zero, the user is logged in
- If needed, the name of the user can be retrieved from the users table with the uid
There may be additional issues related to sessions timing out, and/or auto-logins after sessions have expired, but I have not looked into these yet. I may do that later.
Joomla has served me nicely for quite a while now. But over time I have become frustrated with the lack of "native" comments and forums and the various hacks to get comments/forums working nicely. I've had some success with SMF, but the pain one needs to endure to keep the user database, session cookies and passwords getting lost by themselves finally got to me. The one thing which I still believe is better are the Joomla templates supplied by Drupal templates still seems to be lacking. Thankfully, HTML & CSS isn't that hard anyway (not that I am claiming to be an expert), so with some external inspiration from other websites it is still possible to build something half-decent looking.
In addition to my homepage at kjeldahl.net, I also run a site dealing with investing and trading resources named keelix.com. On that site I actually hook into the CMS system's user authentication and session systems to allow people access to various resources. For simple web-stuff, I'm mostly a perl person, so hooking into foreign authentication and session systems is a bit more challenging than "including" some PHP snippets in PHP code/templates.
Over the last year, the SMF forums have been gradually poisoned by spam that registers as valid users and post their spam in the different forums. Now it may be that SMF and/or Joomla have some nice captcha modules ready to go already, but bearing in mind the troubles I've had with integrating foreign forums, I decided to see if something else could make my life simpler. From what I have seen so far, Drupal seems to be it. It offers commenting, simple forums and captcha modules more or less out of the box. Well, the captcha modules had to be installed separately, but differently from what I experienced with Joomla, the first captcha module I found through drupal.org worked without any trouble. So I decided to switch from Joomla to Drupal.
One of the system on keelix.com is a "backtester", basically loads data for most public US-based companies almost 10 years back with some code which allow testing trading strategies such as "is it profitable to buy companies with a low price/earnings ratio" and "does price momentum with a low book/value work"? If this is greek to you, don't worry, you do not have to know or care about trading to understand what I am trying to do. The point is that running the backtester is very disk and CPU intensive, so I want to know a little bit about who is using it. Since one single backtest can hog the server for anything from 2-200 minutes it is also very important to implement a queuing system to avoid a single user hogging the machine more or less forever by submitting multiple large jobs.
The way the system now works running under Joomla, is basically verifying the state of the SMF cookie that the Joomla/SMF integration is using. If the user is correctly logged in, allow him access to the backtester. If not, tell him to log in first and come back. This will be the same strategy I will be using for Drupal.
Drupal sessions are stored in a table named "sessions". An entry in the table when the Drupal administrator is logged in typically look like this:
=# select * from sessions; uid | sid | hostname | timestamp | cache | session -----+----------------------------------+---------------+------------+-------+--------- 1 | 8289f0651b17de28932f4a9xxxxxxxxx | 84.49.241.217 | 1193903244 | 0 |
After logging out or before logging in, each user is given a session id (sid) which is stored in the sessions table with uid 0. After a successful login, the uid is changed to the actual uid of user who logged in.
So for any "external" program (external to PHP/Drupal that is), it should be sufficient to:
- Look for the Drupal session cookie (the name of it is usually auto-generated when installing Drupal)
- If found, look it up in the sessions table. Search the sessions table where sid equals the cookie value.
- If row is found with the correct sid and uid is anything but zero, the user is logged in
- If needed, the name of the user can be retrieved from the users table with the uid
There may be additional issues related to sessions timing out, and/or auto-logins after sessions have expired, but I have not looked into these yet. I may do that later.