Joyce, > Both Kevin and Rick are providing me with a solution I have been able to > previously and successfully implement but the problem is -- the boss doesn't > want to have fuseactions for the authentication. Only parts of our site are > password protected and ideally he wants to be able to have a call to the > authentication customtag from the app_locals.cfm (fusebox2) for the areas > that require authentication.
OK - in FB2 the way to do it is use the app_secure.cfm template that checks the to see what access rights a user has, if the user isn't logged or doesn't have the appropriate access rights in then the cf_returnfuseaction records where the user is currently attempting to access and redirects them to the login fuse. This method will have the login fuse displayed in the browser, but the form action and hidden fields will "hide" the authentication fuseaction etc. I'm not sure what your boss is after, but you can check to see if the user has access to the accessed resource without going off to another page. I suppose the "no access" situation could be dealt with inside a tag/template by displaying a JS alert box saying go away and then redirecting the user to the home page (or where ever), but if the user is not logged in then you will have to send them off somewhere else to deal with that situations. > Problem is the authentication processes uses a > form to login with and to process that form I can't figure out how to > recursively recall the customtag that creates the form instead of have the > form action go back to a fuseaction in an index.cfm. > I'm not entirely certain why you're recursively calling a custom tag to process the results of a form. Are you saying that the custom tag generates the form and also checks the results of that form? If this is the case then I would recommend that you go back to using fuses. If you have all that code in one template, there is a lot that isn't being used that has to be interpreted each time you call the tag. Plus each call to the tag will cause CF to grab memory from the server to process the tag in. Thinking this through, what you could probably do is, if the user is not logged in call the tag using the attributes that cause a login form to be displayed. You should be able to set the form action using cgi.script_name, so that it will submit back to the same page the user is accessing. When the user submits the login form then call the tag again, just passing through the login details from the form for checking. If the details are valid then just let the user drop out of the bottom of the tag and into the page. If the login fails then display an error and return them to the login form. If the user has insufficient priviledges then tell them and send them off to the home page. This way, you aren't calling the tag recursively, which could lead you into a horrible nightmare of a server in a downward spiral to death if you get it wrong. (honest guv - I haven't done that to a few servers in years gone by ;o) ), leaves the functionality in the tag and doesn't direct you off to a new circuit/fuseaction. Hmm... not my most coherent email to date, more a stream of consciousness, but I hope it helps/makes sense. Regards Stephen ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
