Skip to main content
E
earachefl
Known Participant
July 2, 2010
Question

Site architecture question

  • July 2, 2010
  • 2 replies
  • 685 views

I am working on a fairly basic site which for the most part doesn't require users to log on; it's mostly for viewing dynamic/static information; there's no personalization; no reason to set cookies or application-wide variables (except perhaps the datasource name). There are some administrative pages that allow administrators to log on and add/edit/delete events in an event calendar, perhaps eventually manage some other aspects of the site. My question relates to the overall site architecture. Would it be good design to have all the administrative templates, Application.cfc etc. in a subdirectory of the web site root? If I did that, I was thinking I could have OnRequestStart check all those pages in that subdirectory for GetAuthUser.

Someone had suggested that I have DreamWeaver add the login functionality to those pages, and having done so, I now realize that I don't really have it working properly... haven't figured out how to get Session variables working, how to alert when the session has timed out, and what, if anything, I need to lock when writing events to the database. While waiting for the Forta CFWACK 9 book to arrive, I'm trying to make sense of all the conflicting information on the web, and trying not to tear my hair out (what remains of it).

Thanks

This topic has been closed for replies.

2 replies

ilssac
ilssac
Inspiring
July 2, 2010

Having a administrative sub-directory is a common architecture.  Having a separate web site is also common, it offers some additional capability and functional options and is not all that difficult if one has their own web server to work with as apposed to a shared hosting situation.

If you are having specific problems with setting up sessions, describing what you have done, what behaviors you are experiencing, what errors are occurring and some code samples would allow us to help you out.  Otherwise we can only suggest to follow the documentation.

You only need to lock writing if your database access, if there is a race condition involved in your application.

Your application can't send an alert when the session timeout out.  The server has no connection to the client.  If you want some type of alert, the client has to keep track of it.  This is usually accomplished with a bit of JavaScript logic that sets a client timer of a similar length to the server's session timeout which will generate an alert when it is triggered.

E
earacheflAuthor
Known Participant
July 2, 2010

Thanks to both of you.

Hopefully I can figure out the session variables issues once I study some more and try some stripped down templates.

And thanks for the tip on the session timeout. I had thought that OnSessionEnd could somehow be used to trigger an alert, but adding the JS code should be easy enough.

ilssac
ilssac
Inspiring
July 2, 2010

earachefl wrote:

I had thought that OnSessionEnd could somehow be used to trigger an alert

A common thought by inexperienced web application developers.  Developing and debugging web applications becomes much easier once one clearly understands the client-server relationship and the HTTP response-request cycle they use to communicate.

You are creating various code syntax, HTML, CFML, JS, CSS, SQL, etc.  And each of these code blocks will be run on different systems at different times and in between these various systems will have no conenctions between them.

Owainnorth
Owainnorth
Inspiring
July 2, 2010

Bear in mind an Application.cfc only applies to pages lower down the directory chain to itself, so if you have a /admin directory (or something similarly easy to guess/hack) then you can make an App.cfc in there check authentication on every onRequestStart, without affecting pages on the main site.

I would do what you suggest and just have the admin stuff on an admin directory, or on entirely different site completely which just so happens to look at the same database if that's feasible - means there's no "admin area" at all on your public-facing site.

O.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices