Simplified Cookie-Based Frontend Hack

[jsw_nz]

From what I understand the frontend aspect of phpwcms is due for future release...so posting a thread on another hack/strategy to implement it might be inapproprate at this stage. Nonetheless..I thought I would ask others in the community about advice on how to go about it, since prelims/strategies on a project are pending asap. The Kurty frontend hack that was discussed back in March still has some issues with it, it seems....so a somwhat simplified approach came to my mind. I just finished a hand-coded site that relies on standard php cookies, that exist on conditions of successful login. As long as the user is logged in the cookie is set, the redirect script (checking if cookie is not set) in the header on sensitive pages gets by-passed:

Code: Select all

<?php if (!isset($_COOKIE['logincookie'])) {
	// Output header, send to login if no cookie exists
	header ( "Location: back_to_login.php" );
	exit;
	}

This works pretty reliably. With respect to the project at hand....got a client who wants a small-sized real estate website, with both public pages and private pages (private property listings) that incorporates some sort of forntend/login. So basically the login might be treated by setting a cookie.

I have developed a Flash menu system that would be able to determine the login cookie status and then conditionally spit out XML based on the acat_public conditonal. If logged in..the XML output would list both public and non-public pages. If not looged in (No cookie) then public only pages get listed in the menu. Have a pretty good idea on how to implement this.

The real question is about accessing non-public pages via 'non-menu' methods, ie bookmarks/manually typing in address (uses alaises) in the address. Still need a method to boot non-logged in users from viewing these pages.

So basically my question is where can I successfully the above mentioned cookie sniffer script within the standardized phpwcms implementation. As I understand it works on session cookies, whereas my simplified hack (future tense) might rely on standard cookies. Wanted to ask others their thoughts about how phpwcms might be modified to check for cookie status before running the standard script for page generation.

Thoughts/ideas/suggestions would be appreciated.

Cheers, jsw(john)

[jsw_nz]

I basically got a cookie based hack working, but found in certain situations (windows xp -- sp2) cookies can often be turned off. So I went ahead and did a session-based version.

Basically the hack needed to protect only one category in wcms....a private properties listing (real estate client). My solution is less than ideal and that is why I am posting this topic.

The main issue is to have wcms, when generatating output determine two things:

(1) Is the private page (identified by alias) being requested.
(2) If so does the session variable exist $_Session['Website_Member']

If the var exists, then viewing page is allowed, if not then redirect to the login page. As such it is pretty simple conditional....yet implementing it in wcms...since requisitioning of content comes through the index.php?XXX query..is not clear to me...

At the present time my solution is less than perfect...where a Flash Menu System on the left side of page...does this re-direction...but this happens only after the page has partilially loaded.

You can see the quandry by accessing this page:

http://www.opinz.co.uk/index.php?property
***update now fixed


I wanted to ask if some out there have been able to create a custom hack/code in the 'right location' of wcms to automatically do this redirect, without having to 'partially load' secured pages............

***********************************************
UPDATE:

By putting location header code within the page template (top of main - before any other code), redirection was enabled. the code looks something like this:

Code: Select all

[PHP]if(!isset($_SESSION['OPINZ_Member'])){
header ("location: http://www.opinz.co.uk/index.php?login");
exit;}[/PHP]

It executes pretty robustly and redirects to a login message. The session variable is set on successful login. Works well.....

Cheers,
John (jsw_nz)