ColdFusion designed websites
December 22, 2006 5:22 PM Subscribe
A question for ColdFusion gurus. A guy in our company has used ColdFusion to design a password protected website, and I need to know how it works as ColdFusion is a total unknown to me.
The ColdFusion "entry" page authenticates the clients signing in against a database and then they can view the pages. This works without a problem, but unfortunately his idea of design is horrible to say the least so everything after the sign-in page totally sucks. We have a nice looking website designed by somebody else in the office that we would like to use for the client site, but our ColdFusion guy says that he can't use or integrate anything done by somebody else that is not made using ColdFusion. So after the ColdFusion part has done its part by authenticating the client can we then just "hand it off" to the html/css site that has no ColdFusion in it at all but looks really good? Any advise or maybe a resource I can read up on over the holidays so I can go back next week and hopefully call CF guys bluff and give our client a nice looking website??
The ColdFusion "entry" page authenticates the clients signing in against a database and then they can view the pages. This works without a problem, but unfortunately his idea of design is horrible to say the least so everything after the sign-in page totally sucks. We have a nice looking website designed by somebody else in the office that we would like to use for the client site, but our ColdFusion guy says that he can't use or integrate anything done by somebody else that is not made using ColdFusion. So after the ColdFusion part has done its part by authenticating the client can we then just "hand it off" to the html/css site that has no ColdFusion in it at all but looks really good? Any advise or maybe a resource I can read up on over the holidays so I can go back next week and hopefully call CF guys bluff and give our client a nice looking website??
"...our ColdFusion guy says that he can't use or integrate anything done by somebody else that is not made using ColdFusion."
You need a new ColdFusion guy. Seriously.
The whole point of something like ColdFusion is to do what you're asking, if you're accurately describing the situation.
posted by majick at 6:15 PM on December 22, 2006
You need a new ColdFusion guy. Seriously.
The whole point of something like ColdFusion is to do what you're asking, if you're accurately describing the situation.
posted by majick at 6:15 PM on December 22, 2006
Majick, ColdFusion is actually really shitty when it comes to mixing other runtimes. Fucking waste of energy.
Before I write it all out: Insert what Jaded said here. You still need an authentication system so people can't touch the protected pages behind the login portal, so you've either gotta have the pages served up by ColdFusion, or whatever system is mixed with CF to share authentication.
posted by secret about box at 6:38 PM on December 22, 2006
Before I write it all out: Insert what Jaded said here. You still need an authentication system so people can't touch the protected pages behind the login portal, so you've either gotta have the pages served up by ColdFusion, or whatever system is mixed with CF to share authentication.
posted by secret about box at 6:38 PM on December 22, 2006
Even if the rest of the site uses a different language, you could quickly get a programmer to create the same authentication system in PHP, ASP, or whatever. It wouldn't take them long. But if the rest of the site is just HTML, there's no problem. Or should be no problem. And what Jaded said. Crikes. It's not rocket surgery.
posted by strangeleftydoublethink at 7:30 PM on December 22, 2006
posted by strangeleftydoublethink at 7:30 PM on December 22, 2006
I would like add one more thing: it's perfectly reasonable for a developer to be awful at design. Some programmers just don't have the skill for it. Just like designers usually don't do code. That said, you can't be a web developer if you can't implement someone else's design. It's just part of the job.
posted by jaded at 8:05 PM on December 22, 2006
posted by jaded at 8:05 PM on December 22, 2006
If it's asp/php/jsp etc. it'll be easier to redo the authentication in whatever language the other stuff is in. If it's just html/css, your coldfusion guy is either stupid or lazy. or both.
posted by juv3nal at 8:27 PM on December 22, 2006
posted by juv3nal at 8:27 PM on December 22, 2006
"Majick, ColdFusion is actually really shitty when it comes to mixing other runtimes."
I'm actually aware of this. And to the CF guy's credit, clearly he is as well. However, the developer is being asked to integrate to, and I quote, "the html/css site that has no ColdFusion in it at all but looks really good[.]"
If that's not what ColdFusion is for, what's it do?
posted by majick at 9:32 PM on December 22, 2006
I'm actually aware of this. And to the CF guy's credit, clearly he is as well. However, the developer is being asked to integrate to, and I quote, "the html/css site that has no ColdFusion in it at all but looks really good[.]"
If that's not what ColdFusion is for, what's it do?
posted by majick at 9:32 PM on December 22, 2006
If the developer really says they can't integrate another design/site into their code due to some vague thing about it not being built in ColdFusion (rather than saying it might be difficult or time-consuming due to specific technical issues with the other HTML, which can often be the case), you need to seriously consider ditching them now.
It may be that they've simply used someone else's code to create the authentication system, and/or used Dreamweaver to create the pages, and so have no idea how any of it works. Bluffing is pretty common amongst developers.
posted by malevolent at 1:51 AM on December 23, 2006
It may be that they've simply used someone else's code to create the authentication system, and/or used Dreamweaver to create the pages, and so have no idea how any of it works. Bluffing is pretty common amongst developers.
posted by malevolent at 1:51 AM on December 23, 2006
Yeah, clearly what he's saying is nonsense.
Cold Fusion, whatever it does on the back end, gets information from web forms/pages and sends HTML back.
That's what nearly all such systems do. PHP, Perl, ASP, whatever.
There are other things a website might use, like Java applets or Flash, where that's not the case, but in this case, HTML is HTML is HTML.
If he can't change the HTML that sends the info to CF, or change the HTML that CF sends back, then, as majick says, what's the point of it? Or rather, him.
posted by AmbroseChapel at 4:29 AM on December 23, 2006
Cold Fusion, whatever it does on the back end, gets information from web forms/pages and sends HTML back.
That's what nearly all such systems do. PHP, Perl, ASP, whatever.
There are other things a website might use, like Java applets or Flash, where that's not the case, but in this case, HTML is HTML is HTML.
If he can't change the HTML that sends the info to CF, or change the HTML that CF sends back, then, as majick says, what's the point of it? Or rather, him.
posted by AmbroseChapel at 4:29 AM on December 23, 2006
I think your ColdFusion guy is saying that session state (i.e. logged-on or not) cannot be maintained across different backend applications. While this is not true, it is true that doing so securely is fairly complex. So the first thing to determine is whether that is necessary. If it is important that users/hackers never reach Site B without authenticating through Login Form A, maintaining session state is required.
There are any number of solutions for this situation. JavaScript could do the job if you are using static HTML on Site B. The server-side technology that is serving Site B has no impact on ColdFusion (either it is a different server, it is static HTML, or another server application is running on the same server but you don't want to require CF interact with it directly). Rewriting the site in one language that would maintain session state may be the simplest solution to have implemented but is not technically required.
All that said, it sounds like your ColdFusion guy is either lazy or not experienced enough to handle site security.
posted by McGuillicuddy at 7:40 AM on December 23, 2006
There are any number of solutions for this situation. JavaScript could do the job if you are using static HTML on Site B. The server-side technology that is serving Site B has no impact on ColdFusion (either it is a different server, it is static HTML, or another server application is running on the same server but you don't want to require CF interact with it directly). Rewriting the site in one language that would maintain session state may be the simplest solution to have implemented but is not technically required.
All that said, it sounds like your ColdFusion guy is either lazy or not experienced enough to handle site security.
posted by McGuillicuddy at 7:40 AM on December 23, 2006
Best answer: In my experience, this issue usually comes down to ColdFusion not having a way to protect non-CF content from non-authenticated users, particularly in an IIS environment, where you're most likely to find ColdFusion and don't have Apache's more straightforward access control.
One trick I've done in the past (for protecting PDF content and the like) was to use an ISAPI filter that can control the content, usually along with some ASP stuff to manage the session. Log the user in in CF, and then fire off the ASP session management stuff, and you're good to go. You'll typically have to play some tricks to keep the sessions (both CF and ASP) in synch, but it's not all that terribly difficult.
There are several ISAPI filters that fit the bill, ranging from cheap to free.
If the entire new site is truly HTML/CSS (and doesn't run any other scripting language, and you don't need to protect things like PDF files), and server overhead isn't an issue, an even easier approach is to just have the ColdFusion process handle all of the HTML -- you can tell IIS (for that site) to treat all .HTM/.HTML files the same as your .CFM files, or rename the HTML files to .CFM.
Doing it this way, you can handle all of your session management in ColdFusion the same way you'd normally do it. ColdFusion parses the HTML files, doesn't find any CF commands, and just sends them on to the (authenticated) user unchanged.
posted by nonliteral at 11:32 AM on December 23, 2006
One trick I've done in the past (for protecting PDF content and the like) was to use an ISAPI filter that can control the content, usually along with some ASP stuff to manage the session. Log the user in in CF, and then fire off the ASP session management stuff, and you're good to go. You'll typically have to play some tricks to keep the sessions (both CF and ASP) in synch, but it's not all that terribly difficult.
There are several ISAPI filters that fit the bill, ranging from cheap to free.
If the entire new site is truly HTML/CSS (and doesn't run any other scripting language, and you don't need to protect things like PDF files), and server overhead isn't an issue, an even easier approach is to just have the ColdFusion process handle all of the HTML -- you can tell IIS (for that site) to treat all .HTM/.HTML files the same as your .CFM files, or rename the HTML files to .CFM.
Doing it this way, you can handle all of your session management in ColdFusion the same way you'd normally do it. ColdFusion parses the HTML files, doesn't find any CF commands, and just sends them on to the (authenticated) user unchanged.
posted by nonliteral at 11:32 AM on December 23, 2006
Response by poster: Thanks all. Given all this, it's time to call CF guys bluff next week.
posted by 543DoublePlay at 12:12 PM on December 23, 2006
posted by 543DoublePlay at 12:12 PM on December 23, 2006
Have your coldfusion guy make his protected login at say:
example.com/login
Once logged in properly, redirect them to here:
example.com/clients
Toss any HTML/CSS files you want there, as long as you also include an application.cfm file that requires that they have a cookie (otherwise, kick them to /login). Any CF person can write the application.cfm file in about 30 seconds.
This is pretty much how all of MeFi works. It's really braindead simple and I wrote it over 7 years ago after 2 hours of reading about ColdFusion for the first time.
posted by mathowie at 12:26 PM on December 23, 2006
example.com/login
Once logged in properly, redirect them to here:
example.com/clients
Toss any HTML/CSS files you want there, as long as you also include an application.cfm file that requires that they have a cookie (otherwise, kick them to /login). Any CF person can write the application.cfm file in about 30 seconds.
This is pretty much how all of MeFi works. It's really braindead simple and I wrote it over 7 years ago after 2 hours of reading about ColdFusion for the first time.
posted by mathowie at 12:26 PM on December 23, 2006
« Older How to automatically lock workstation upon logon... | Question regarding the way TV commercials are... Newer »
This thread is closed to new comments.
If so, then unfortunately, your CF guy may be at least partly right, especially if he doesn't know the platform. It's generally not a good idea to mix application service providers (coldfusion, asp, perl, php, etc). Making them share authentication can be a pain in the ass. It's doable, but.....using CF to handle authentication (login) and then handing it off to some other application server (php, or something) is unlikely to be reasonably secure, especially if your developer is dweeb.
BUT. If the rest of the site is really just html/css, then ANY CF developer should be able to take the raw html and integrate it into an existing site. Part of a web programmer's JOB is to take raw HTML layout and/or designs and implement them within existing application frameworks. It's called division of labor. Designers design. Web developers develop. If he can't or is unwilling to do so, then you need to find a real developer.
One of the great things about CF is that a retarded monkey can learn the language. One of the problems is that they often do.
(As for specific resources, I'll be no help. I learned the language by reading the manual (already having years of exp. in other languages). sorry)
posted by jaded at 5:59 PM on December 22, 2006