Theme Builder Plugin

[All Adaptavist Apps]

Page tree

  • Created by Unknown User (farleyw@amerch.com), last modified by Unknown User (amoran) on Feb 25, 2008

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.

12 Comments

  1. Unknown User (gfraser)

    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 (wink)

    Atlassian's Product EULA (clause 7.d) states:

    (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.

    As a result, our Theme Builder EULA (clause 8.4) exists:

    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 | ...
Site powered by Atlassian's [Confluence|ADAPTAVIST:Confluence] wiki customised
with Adaptavist's [Theme Builder|ADAPTAVIST:Builder] and [Community Bubbles|ADAPTAVIST:Bubbles] plugins.

    (Edited markup to stop page width going crazy)

    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 (smile) For a full tutorial on how we did the design of our website, see Adaptavist Website Theme v4 in our Tutorials section.

    Theme Builder 4.0 Milestone 9 and above

    Please note that we've changed the ID of the attribution message from 'poweredby' to 'attribution' in Builder 4.0 M9 and later.

  2. Unknown User (kelvin.olson)

    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?

    1. Unknown User (gfraser)

      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.

      1. Unknown User (kelvin.olson)

        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

        1. Unknown User (gfraser)

          Out of interest, which operating system are you hosting your site on?

          1. Unknown User (kelvin.olson)

            Intranet system currently being built will be SunOS 5.9, or thereabouts. I was about to start installing, when one of the admins said "Oh, wait, that box still has the beta solaris. Let us install a good OS first."

            The public website (the marketing stuff) sits at bluehost. Don't remember if it's Windows, Linux, or other.

            Confluence Standalone is running on Mandrake now, but is moving to Sun after that server is ready for me to migrate.

            One space of our Confluence is the middle ground between low-tech marketing content writer and myself. I've got lots of experience with html (etc.), but too many higher priority tasks to act as the marketing team's stenographer.

            But as you can see, there are two sides to this.

            1. What can be done, technically, feasibly.
            2. What WE can do, while remaining practical.

            Well I'm off - to try to write my first user macro. Oy.

            1. Unknown User (amoran)

              You should probably be more concerned about the host OS than the footer text (wink) Any 13yo skript kiddie can tell you the difference between cracking a doze box compared to linux or even openBSD!

              Even on the first page-load it is highly likely that the combinedcss will have loaded before the footer gets rendered, and as guy mentions the domain.com/display/SPACEKEY/pagename format is just as recognisable as teh footer text, and it doesn't even require you to download a page!!

              Good luck with the user macro .. tbh I found coding java macros FAR easier than the user ones, with velocity you have to get pretty inventive about where/how you get your information from, wheras in java you just grab it and it is there already!

        2. Unknown User (amoran)

          http://confluence.atlassian.com/display/DOC/Confluence+to+HTML

          1. Unknown User (kelvin.olson)

            Exactly - that is how I planned to get the wiki-edited pages to static html.

            ...and after a bit more poking around, I have come across...

            Page.htmlexport.vm

            I suspect I'll be working on a custom one of those. Even better if we can convince management to hire a qualified website designer to revamp the site with a good template, and have them work with it via this export thing. This has potential to not be a nightmare. Wish us luck.

            1. Unknown User (amoran)

              I see no reason why you cant repurpose the output of builder to generate your own static site, there may be however issues with you using it to generate content for 'client sites' .. ie: sites you have been paid to generate/maintain.

              I should mention that it does appear as though you may be missing the entire point of builder ... the idea is to have a website that is fully editable, but commercially secure enough to prevent 'external' users from modifying content.

              1. Unknown User (kelvin.olson)

                Response to para 1: Good. And we have no intention of doing sites for anyone else. This is just for our site.

                Response to para 2: Well we used to have our website hosted on a trio of webservers behind a load balancer, but that setup was designed for the interfaces we build for customers to access our backend systems (accounting software - exciting stuff). But we recently decided that the marketing site (for people who are not yet our customers) should be someplace other than the servers our current customers use to do their work.

                I was considering possibilities and options for what we could do, if we decided to host our own again. I'd be able to hand it over to the marketing team, and say "Call me if you break it."

                But if we can tune it right, merely export-and-upload when they have finished a change, that's not too bad. I can live with that.

  3. Unknown User (seaworthy)

    To hide the text in Confluence 3.1/Builder 4, the following works:

    #attribution > div {
 display: none;
 visibility: hidden;
}