wow, lots of questions, and so early in the morning. I've given my opinions, though i'm still on my first coffee so usual disclaimer applies.
Bert > -----Original Message----- > From: Kasey Chang [mailto:[EMAIL PROTECTED]] > Sent: 14 June 2002 04:00 > To: [EMAIL PROTECTED] > Subject: Repost: Questions about FB3 > > > This is a repost as I didn't notice any answers and I had to > switch mail accounts (Hotmail keep dumping the digest > into the Junk Mail folder, and my alternate account keeps > going into dev/null! ) > > FB newbie have several questions about FB3... I've read > all the presentations on fusebox.org. I actually got applications > WORKING but I can't find answers to these questions. > > 1) In a "login" module, there are cases where you need to > look at a query and decide where to branch to. Is that > considered a query module or an action module? You could either stick it into one file, or separate the query, the decision, and the redirection into separate files, or separate the query out, then have a little <cfif> to decide whether to let them in or kick them out. > > 2) What is the "better" way to maintain session when using > CFLOCATION? Should I use the custom tag CF_LOCATION > instead? I see a lot of code in samples (like the TaskManager > I got from Fusium) that uses BOTH... If success, CF_LOCATION > is used to continue (I presume to keep the CFID/CFTOKEN > cookies?) and if failed CFLOCATION is used to jump to "login > failed" page. Did I understand that correctly? What are the > implications of using the wrong one? you can't use cflocation in the same request as setting a cookie (cos of http headers and stuff AFAIK). CF_location (i think there are a couple of different versions around) uses javascipt so the client gets the whole request and the cookies get set before the re-location occurs > > 3) I was reading the CFDJ on those articles about maintaining > sessions and how to prevent session hijacking and all that. I am > working on an app that deal with some financial information and > need session and security. I found the "Fusebox Security Model" > sample app (the one from onshop.com) but I don't need multilevel > security in this case. Is there a simpler session/access app > available for reference? I think this is a separate security issuefrom that addressed by "Fusebox Security Model", though i'm assuming the one on onshop.com is something like Hal Helms'. You'r talking about session hijacking, which is different to restricting/granting access to areas based on the current users rights (or roles or permissions or whatever) > > 4) How DOES one handle session timeouts in terms of fusebox? same as non FB > Should there be a fuseaction about session timeout? If you want to end a session then your "logout" fuseaction might make use of a fuse that timesout the session using stuctclear, but not by messing with the sessiontimeout attribute of the cfapplication tag. > > 5) I also read in CFDJ about that CF_REQUEST tag which > makes ANY request scope variable into session or client scope > and vice versa. It sounds good, but it seems to have some problems > as fusebox uses a LOT of request scope structures and such. Does > that work with Fusebox at all? What are the implications? I think this was proposed as a method to get around all those unlocked accessing of the session scope, and there are arguments for and against. I think it depends on how much stuff you store in the session scope, and how often you access it, which will decide whether you want to take the performance hit on copying the whole thing to the request scope and back just for the convenience of not locking access to it. (though i'm not aware of any benchmarks - i think its one of those instinct/suspicion things, and as such probably well inaccurate...) Also, i think it would definately be a _bad_ idea just to copy everything from the request scope into the session/client scope and back - if you're going to do it it'd be better to create a structure in the request scope and use that for your lock-free persistent variables. And you'd have to make sure you do this copying to session/client scope before any cflocations (unless you use cf_location...) BTW, FB uses request scope no more or less than non-FB - some people love them, others consider them the most evil thing since something quite evil. > > 6) There are some cases where a "fixed entry and exit" point is not > desirable. For example, if I called screen A from screen B, I would > want screen A to return to screen B. Yet if I called screen A from > screen C, I would want to return to C. How do you handle that in > FB3? It seems that XFA is pretty "fixed" when it comes to the > 'return' paths. > > In a wireframe, you need to code two or three separate exit > pts to reflect situations like this. > > Right now I'm passing a URL scope variable called > OFA (original fuseaction) but I'm not sure if that's the "right" > solution. > > I have more questions but those can wait. :-) > > --remove NOSPAMYOUIDIOT to reply, [EMAIL PROTECTED] is invalid-- > K S C H A N G (AT) PC Guru, web developer, gamer, Trekker > E X C I T E (DOT) COM database developer, idea man, IT guy > --If it looks too obvious, it probably is. -- anonymous > > > ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
