Is there a way to change the powered by text at the bottom of the page. I have changed it in the global site layouts but the theme builder spaces do not seem to be using it.
Apologies in advance for this comment being a bit verbose, but there are legal aspects to it and it's a very common question so I'm answering several forms and aspects of this question in one go
(d) with respect to any use of the Product, include an attribution to Atlassian to be included on all user interfaces in the following format: "Powered by Atlassian", which must in every case include a hyperlink to http://www.atlassian.com, and which must be in the same format as delivered in the Product.
8.4 with respect to any use of the Theme Builder Product, provide an attribution to both Adaptavist and Adaptavist which is to be included on all user interfaces customised with the Product in the following format: "Adaptavist Theme Builder powered by Atlassian Confluence", which must in every case include a hyperlink to http://www.adaptavist.com and http://www.atlassian.com respectively.
Specifically, with prior written agreement from Atlassian, this allowed the default attribution line to be shrunk from something like this:
Powered by Atlassian Confluence 2.7.1, the Enterprise Wiki. Bug/feature request - Atlassian news - Contact administrators
To this:
Adaptavist Theme Builder powered by Atlassian Confluence
However, on our website you'll notice that we've further customised the footer. We were able to do this because we retained the visible attribution statements by adding the following notation to the Footer panel:
{copyright} 2007 Adaptavist.com Ltd.{copyright} All rights reserved worldwide | Registered in England and Wales #5456785 | VAT Reg. GB 872 1217 39 | EIN: 98-054 5295
Site powered by Atlassian's [Confluence|ADAPTAVIST:Confluence] wiki customised with Adaptavist's [Theme Builder|ADAPTAVIST:Builder] and [Community Bubbles|ADAPTAVIST:Bubbles] plugins. | [Privacy Policy|ADAPTAVIST:Privacy Policy] | [Terms of Use|ADAPTAVIST:Terms of Use]
We then hid the "powered by" footer (which is otherwise uneditable to ensure at least some compliance with EULA's regardless of how the theme is customised) using CSS:
#poweredby {
display: none;
visibility: hidden;
}
The result can be seen at the bottom of this web page For a full tutorial on how we did the design of our website, see Adaptavist Website Theme in our Tutorials section.
All that is well and good, and I understand. BUT...
With any wiki, content management system, what-have-you, eventually somebody somewhere is going to find a security hole. Then they're going to write an evil robot that searches google for all sites that can be identified as using that particular system, so as to try to make the greatest exploit of that security hole until such time as it is plugged.
So, for the intranet, behind the firewall, no problem complying with that "you must give us credit and brag about how great we are" clause of the EULA.
But for a site publicly exposed to the internet, it would be, for completely reasonable security considerations, be my intent to make the site look entirely like it is a 100% static html site, built with UltraEdit, or Notepad, or vi for that matter. That is, "Don't even bother knocking, there is nothing interesting or hackable here. Go play somewhere else."
You see, I've been messed with in such a manner before (using a L.A.M.P.-based CMS). And they didn't target the sites I'd designed because of the content or political reasons or whatever. Nope - the only reason we were targeted is because the "powered by" text at the bottom of each and every page of these websites made them all easy to find via google (or any other search engine).
So - ideas about a compromise. How about a graphic that contains the same line of text, in a non-robot-searchable manner, which is then linked to a tinyurl that makes the connection to your website (and Atlassian's) a somewhat more anonymous trail that an human would figure out, but the robots wouldn't as likely?
OR - how about if our internal, editable version of the site (one of the spaces in our wiki intranet, behind the firewall) allowed us a way to export a public version that is 100% static html, but still works almost exactly the same? I don't think we need login, or comments, and maybe not even search (let google do that). Workable?
What you are suggesting is akin to: "I'm going to store all my money in a paper bag in full public view but I'm going to make it look like a road sign so thieves will ignore it".
The common exploits that you'd get on something like phpBB2 or other script based web apps don't apply to J2EE applications - it's a completely different architecture.
Confluence is heavily security tested on an ongoing basis by organisations worldwide and known security exploits are quickly reported to Atlassian and plugin vendors which are then quickly fixed (usually with patches for older versions of the product).
Theme Builder 3 allows you to turn off debug information on the Options Tab allowing you to remove version numbers from the attribution.
Even if there was a graphic, it's still not much of a challenge - just as human readable CAPTCHA graphics (where you have to type in the word to post a comment, etc) are easily readable by spammers OCR software, a graphical attribution would also have the same problems. Likewise, a tiny URL is just as recognisable as a normal URL as far as a computer search is concerned.
It should be noted that the URL patterns in Confluence are as much a give away as the attribution line is, as is the presence of "Confluence" string on the login screen, PDF exports, etc. and things like main-action.css style sheet (this too can be switched off in Builder 3.0 and above on the CSS Tab), etc. Any large enterprise web app is literally covered with "fingerprints" that a hacker can use to determine it's nature.
I think we'll have to go with something that is editable by an intern, version-tracked by something-in-between (maybe Confluence, maybe something else), and uploaded as static HTML to the public site.
It makes for a more work-intensive solution, but the best possible hardening against troublemakers.
Doesn't matter how fast an exploit is plugged or patched, if the site's administrator is on vacation.
Oh well. T'was a thought.
If we were bigger, and had more content changes to make, and more frequently, we'd hire a full-time webmaster. Then the webmaster would manage a completely static site. But we're not big. We're small. So the content is being changed infrequently, by people for whom web development is NOT their strong suit. "Why can't we just use MS Word?" sigh I showed them the plain HTML text, and said "you'll just edit this in Notepad" and they got an expression that I interpreted as a combination of fear and nausea.
My next step was going to be to explain how to use CVS to check-in their edits... but I decided not to get into it.
I'd like to see comment on my last suggestion, though. If we Wiki'd the internal, version-controlled space, then when it got management approval, it was exported to static HTML to be put online... does that still need to be attributed as "powered by", since it really isn't, at that stage? Frankly, by that point the site will be about as un-cool as you can imagine, so you probably don't want to take any credit! heheheh
Added by
Apologies in advance for this comment being a bit verbose, but there are legal aspects to it and it's a very common question so I'm answering several forms and aspects of this question in one go
Atlassian's Product EULA (clause 7.d) states:
As a result, our Theme Builder EULA (clause 8.4) exists:
Specifically, with prior written agreement from Atlassian, this allowed the default attribution line to be shrunk from something like this:
To this:
However, on our website you'll notice that we've further customised the footer. We were able to do this because we retained the visible attribution statements by adding the following notation to the Footer panel:
{copyright} 2007 Adaptavist.com Ltd.{copyright} All rights reserved worldwide | Registered in England and Wales #5456785 | VAT Reg. GB 872 1217 39 | EIN: 98-054 5295 Site powered by Atlassian's [Confluence|ADAPTAVIST:Confluence] wiki customised with Adaptavist's [Theme Builder|ADAPTAVIST:Builder] and [Community Bubbles|ADAPTAVIST:Bubbles] plugins. | [Privacy Policy|ADAPTAVIST:Privacy Policy] | [Terms of Use|ADAPTAVIST:Terms of Use]We then hid the "powered by" footer (which is otherwise uneditable to ensure at least some compliance with EULA's regardless of how the theme is customised) using CSS:
#poweredby { display: none; visibility: hidden; }The result can be seen at the bottom of this web page
For a full tutorial on how we did the design of our website, see Adaptavist Website Theme in our Tutorials section.
All that is well and good, and I understand. BUT...
With any wiki, content management system, what-have-you, eventually somebody somewhere is going to find a security hole. Then they're going to write an evil robot that searches google for all sites that can be identified as using that particular system, so as to try to make the greatest exploit of that security hole until such time as it is plugged.
So, for the intranet, behind the firewall, no problem complying with that "you must give us credit and brag about how great we are" clause of the EULA.
But for a site publicly exposed to the internet, it would be, for completely reasonable security considerations, be my intent to make the site look entirely like it is a 100% static html site, built with UltraEdit, or Notepad, or vi for that matter. That is, "Don't even bother knocking, there is nothing interesting or hackable here. Go play somewhere else."
You see, I've been messed with in such a manner before (using a L.A.M.P.-based CMS). And they didn't target the sites I'd designed because of the content or political reasons or whatever. Nope - the only reason we were targeted is because the "powered by" text at the bottom of each and every page of these websites made them all easy to find via google (or any other search engine).
So - ideas about a compromise. How about a graphic that contains the same line of text, in a non-robot-searchable manner, which is then linked to a tinyurl that makes the connection to your website (and Atlassian's) a somewhat more anonymous trail that an human would figure out, but the robots wouldn't as likely?
OR - how about if our internal, editable version of the site (one of the spaces in our wiki intranet, behind the firewall) allowed us a way to export a public version that is 100% static html, but still works almost exactly the same? I don't think we need login, or comments, and maybe not even search (let google do that). Workable?
What you are suggesting is akin to: "I'm going to store all my money in a paper bag in full public view but I'm going to make it look like a road sign so thieves will ignore it".
The common exploits that you'd get on something like phpBB2 or other script based web apps don't apply to J2EE applications - it's a completely different architecture.
Confluence is heavily security tested on an ongoing basis by organisations worldwide and known security exploits are quickly reported to Atlassian and plugin vendors which are then quickly fixed (usually with patches for older versions of the product).
Theme Builder 3 allows you to turn off debug information on the Options Tab allowing you to remove version numbers from the attribution.
Even if there was a graphic, it's still not much of a challenge - just as human readable CAPTCHA graphics (where you have to type in the word to post a comment, etc) are easily readable by spammers OCR software, a graphical attribution would also have the same problems. Likewise, a tiny URL is just as recognisable as a normal URL as far as a computer search is concerned.
It should be noted that the URL patterns in Confluence are as much a give away as the attribution line is, as is the presence of "Confluence" string on the login screen, PDF exports, etc. and things like main-action.css style sheet (this too can be switched off in Builder 3.0 and above on the CSS Tab), etc. Any large enterprise web app is literally covered with "fingerprints" that a hacker can use to determine it's nature.
You make a good point, and charming analogy.
I think we'll have to go with something that is editable by an intern, version-tracked by something-in-between (maybe Confluence, maybe something else), and uploaded as static HTML to the public site.
It makes for a more work-intensive solution, but the best possible hardening against troublemakers.
Doesn't matter how fast an exploit is plugged or patched, if the site's administrator is on vacation.
Oh well. T'was a thought.
If we were bigger, and had more content changes to make, and more frequently, we'd hire a full-time webmaster. Then the webmaster would manage a completely static site. But we're not big. We're small. So the content is being changed infrequently, by people for whom web development is NOT their strong suit. "Why can't we just use MS Word?" sigh I showed them the plain HTML text, and said "you'll just edit this in Notepad" and they got an expression that I interpreted as a combination of fear and nausea.
My next step was going to be to explain how to use CVS to check-in their edits... but I decided not to get into it.
I'd like to see comment on my last suggestion, though. If we Wiki'd the internal, version-controlled space, then when it got management approval, it was exported to static HTML to be put online... does that still need to be attributed as "powered by", since it really isn't, at that stage? Frankly, by that point the site will be about as un-cool as you can imagine, so you probably don't want to take any credit! heheheh
Out of interest, which operating system are you hosting your site on?
http://confluence.atlassian.com/display/DOC/Confluence+to+HTML