Re^4: Hide Data based on account

Actually it is already using sql server and populating user information for authentication from there. The grouping by permissions is also there but needs to be expanded upon. For the time being my task is to change the content displayed based upon the referrer, which is already being captured, for the new product my pass through preauthentication script is not currently working, my guess is that they are not using md5 authentication which the other division of the company is using, however I could be wrong about that it could just be located elsewhere in the other products userinformation - database, as a short term workaround I have it response->redirecting to a static page, which is context sensitive based upon a topic being returned by the query string all that currently displays is the relevant portion of the help file. Users can also login to the site with their user information and that does work but doesn't map to my static page, its a generated page, using xml and xslt to display the content dependent on what xml files are present for that specific site, there are 55 or so old sites that work just fine this way, I need to change the content so some of the "generic" content for the old 55 sites don't come through in the "new" sites. I hope that made sense. I am thinking perhaps a Switch structure would work well here but I am not certain where I should put this switch, it needs to make the decision before it starts creating the page, problem is the original author was using many includes..so does it go in all the include files...and branch off to other subs instead of the originals?

Comment on Re^4: Hide Data based on account

Replies are listed 'Best First'.

Re^5: Hide Data based on account
by snopal (Pilgrim) on Oct 02, 2007 at 15:35 UTC

It is clear you need to define some form of permission map and decide how to implement it. The problem is; what strategy to use.

Ask ten developers and get ten answers, most of which won't apply to your specific situation. It really boils down to what you are willing and capable of doing with the resources you have. If you find that the components you have don't supply enough information to make a decision in every case, then you are going to have to develop that yourself. If you do have all the information, but don't have a strategy to implement the decisions, START SIMPLE.

It is not a sin to have your entire logic tied to an IF logic tree, especially initially. Don't over-complicate your solution just because you are looking for elegance. If elegance comes to you, and it provides the solution you are looking for, well... excellent!

A strategy that is useful is compartmentalizing. If you have this THING that needs to only show when a set of values align. Go for it. Make it a TRUE/FALSE subroutine, and then move on. Solve each situation similarly. You are bound to find some overlap. When it is natural, combine or re-use. As you go along, some patterns may emerge that speaks to you of a clear and elegant solution to large portions of your already written logic. Good for you.

The sin will be worrying about optimizations and elegance too early. Don't do that. It will drive you insane. Start simply, make sure it completely works for the situation it was designed for and move on. If you write readable code, comment where necessary, and don't sweat the beauty of it all, you may find you have created a completely suitable solution after all.

[reply]


Your skill will accomplish what the force of many cannot
	PerlMonks