Multiple Fuseguard versions for single ColdFusion Instance

[Manoj36229141q88d]

Hello,

We are currently trying to upgrade fuseguard from 2.4 to 3.6. 

However , we wanted to see if we can still keep the old one intact and the new one in audit mode or something ,so we just see the logs but nothing gets blocked using the new version.

In other words, is it possible to have two fuseguard versions being used or integrated with one single instance of coldfusion 2023.

Appreciate if anyone could provide with any inputs based on your experience.

Thanks,

Manoj.

[Charlie Arehart]

Yes, you can. Two things.

First, this is no different than would be true of ANY cfc. While some would rely on cf finding it via a mapping defined in the cf admin, you can instead define the mapping at the application level (in application.cfc or application.cfm). Those could each point to a different path, where the FG cfc would be found, perhaps as different versions. 

In fact, you don't technically even NEED to use a mapping: you could put the FG cfc and supporting files instead in a folder within some given application, relying on your application to then load the cfc from THAT subfolder. Of course, having more than one copy of a cfc is generally to be avoided, which is why instead one typically locates it via a mapping instead. Again, see above.

Consider also that if you use the database configurator feature for FG, you'd want to use a different database for each version during such testing. 

Second, while it's OK to ask here, note that FG is owned by Pete Freitag and his company Foundeo. He might even offer a different/better suggestion.

He offers free direct support to those who license his products. You could use the chat or contact form feature offered at https://foundeo.com/.

Or let us know if the above helps or not, or if you have further questions on it. 

[Manoj36229141q88d]

@Charlie Arehart Thanks for the response . I did approach him before posting it here and he said , 'just need to have two sets of code in your Application.cfc/cfm file, and use a different variable to reference each version.' Also, he told me that he didn't try the scenario I wanted to use. So, I wanted to check if anyone here has any thoughts.

[Charlie Arehart]

I find that a curious response from him. But I suspect that either he said something different to you, or you said something different to him (perhaps more or less) than what you offered here.

Regardless, what do you think of what I offered? Have you considered it, or better have you tried it yet?

Or is it perhaps that you're not a developer, and don't really understand what I've said? If so, don't hesitate to admit it. We can never know here "who knows what". As such, we try to find a balance between providing too much vs too little info. 🙂

Or perhaps Pete will soon pop in with his own clarification of things. I'd always defer to his wisdom and experience on any questions related to his tools (and pretty much anything else!) 

[Manoj36229141q88d]

yes,  I  have followed what you have just said. I'm going to try it and respond here once I have the results.  my whole intention was to see if anyone  actually made an attempt to run multiple fuseguards when they are testing an upgrade or an idea if this actually possible. 

Hope I made myself clear. Thanks

[Charlie Arehart]

Manoj, in your desire to make yourself clear, I sense that you still think there's something specific to fuseguard about your question. I appreciate how you could have that fear. I'm curious: did you implement it or did someone else?

Whoever did might recall that it's something one must implement in each application. There's no "global" nature to it. Every application.cfc must load it (by extending from it), and every application.cfm must load it (such as using createobject or cfobject) and typically storing that instance in the application scope.

But it's that LOADING step where one names the path to the folder holding the cfc. Typically that's called "fuseguard", but it's just a convention. That path can again be either a real folder within that app, or it can be a mapping (pointing to a folder stored anywhere).

And you could either define that fuseguard mapping at the app level (to point to version "a" in one app and version "b" in another app). Or you could even define a new admin mapping called "fuseguardnew" (or "fuseguardbob") and have that point to the new version in a DIFFERENT folder, to be shared by any apps which then use THAT name when they load the cfc.

Sorry if my repeating myself (and elaborating) is more annoying than helpful. I'm just trying to stress this is not really a fuseguard-specific question, needing a reply only from someone who has "done it" (run two versions at once). With the operation clear, hopefully it at least gives you more confidence in giving it a go. And maybe the details will help future readers.

They and I (and Pete) will surely look forward to hearing how it goes. 🙂 

[Charlie Arehart]

One more point of clarification: the FG dashboard/manager ui is found within the folder of whatever version you implement. You could then set that up to be accessible via a web server, and that could be different paths for different versions. Again, the DATA read by that is controlled by the confgurator for that app, and your different apps and managers could use different databases for where they store their data.

That can be one for all apps, typically. Or it can be different for different apps. I'm just saying that datastore WOULD need to be aligned with the FG version of the app (or manager).

Hope that's helpful. 

[pete_freitag]

Yes, running multiple versions in the same request is not something that most people do, but I think you can get it to work. That being said it is not the typical way it is used, so there could be something I'm not considering with respect to the two versions you are using. Either way if you run into any errors I'm sure I can help you resolve them - just let me know.

[Charlie Arehart]

Sorry I missed seeing your reply here last week, Pete.

I'm curious though: you refer to this as if you're understanding Manoj wanting to run "multiple versions in the same request", which as you note "is not something that most people do"--and which I've never fathomed anyone wanting. 🙂

But instead what Manoj was asking was, "is it possible to have two fuseguard versions being used or integrated with one single instance of coldfusion 2023." (from his initial post here), which is of course very different.  And THAT is what I've been responding to, throughout here. 

And as I noted in an earlier reply to Manoj, I'd wondered if perhaps what he told you (in his direct email) was different than what he wrote here.

So Manoj, which is it? Or Pete, if you see now how this is what he meant, does it change what you might suggest? 

[pete_freitag]

Yes, I could have misunderstood question. I concurr with Charlie - it should not be a problem to have two fuseguard instances running on the same server - you can just run each in their own application scope. Two versions on the same request should be possible but is not something I've tried.

[Manoj36229141q88d]

@Charlie Arehart  Sorry. maybe I should have been more specific. What I meant was  "multiple versions in the same request (i.e  running on the same app) on a single instance".  I suspect anyone would do it but wanted to ask here if anyone has every done it !

What Pete mentioned aligns with what I was asking, or at least with my interpretation of it.
Anyway, I do understand the potential issues we might face by doing this, so we’ve decided not to proceed further and instead treat FuseGuard as a regular upgrade.

I truly appreciate both of you for your responses.

[Charlie Arehart]

Um, OK. I stand by what I said. You SHOULD have no problem with what you originally asked here: wanting to "have two fuseguard versions being used or integrated with one single instance", given what I offered in reply above.

What you ask for now honestly makes no sense to me, "multiple versions in the same request (i.e running on the same app) on a single instance". I can't fathom what that even means.

FG is a cfc that's typically instantiated into the application. Once that's done, then like any cfc you can't just expect to somehow flip between versions of the cfc--whether FG or otherwise. That's pretty much the whole point of instantiating it into the app: that's done once for the benefit of all requests in that app.

I get it: you're dropping the idea. But you can do what I said: point to the new version while keeping the old one around, to go back to it if you want. It need not be removing the old to make way for the new...at least as long as you consider the couple of issues I'd raised. If you opt not to, OK. I offered the clarification for what you asked for here, which still could benefit you or other readers.