Loading Profile...
Is Javascript supported in PBwiki 2.0?
The "improved" 2.0 editor strips out Javascript tags when inserted in the source. Hundreds of very active wikis use Javascript; how will they be affected?
I’m not surprised
7 people have this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
The best answers from the company
-
Let me offer a clear and official response: we've _temporarily_ disabled arbitrary Javascript on 2.0 wikis to beef up our security infrastructure and make it harder for 2.0 users to have their sessions stolen. We know people want to hack on PBwiki, drop in javascript widgets from other sites, etc. and we'd like to be a great platform for that. So we're looking at ways to let people safely experience the joys of javascript.
Guy: your suggestion about letting only Admins save JS seems reasonable until you realize that the next Writer to edit the page after the Admin adds some JS would cause the JS to be stripped out...unless the JS is specially "signed" in some unmodifiable way. And one of our engineers (Mark, per above) is looking into ways to do such block code signing as we speak.
We may also consider letting users toggle a "Tomfoolery Mode" where they can let people in to do whatever they want (e.g. letting anonymous users slap in javascript) but acknowledge that they are in Wildly Unsupported Land and are liable to shoot themselves in the foot.
We apologize for the temporary inconvenience of having Javascript offline in 2.0 and look forward to letting people tool around again with it as soon as we've made it just a touch safer to do so.
The company and 1 other person say
this answers the question
-
There are all sorts of evil things you can do with JavaScript, ranging from stealing cookies to redirecting you to unsavory destinations.
The reason the HTML plugin in edit mode is filtered when the Custom HTML is not is because the Custom HTML can only be edited by an admin, someone who is presumably trustworthy. Especially on public wikis, allowing anyone to insert a chunk of random JavaScript would be incredibly dangerous.
As for the “not very Web 2.0” statement, I think you'll find that JavaScript is stripped out pretty much everywhere. JavaScript getting through the cracks means the potential for Cross-Site Scripting attacks, and those are no good.
The bottom line is that we're continually hardening PBwiki 2.0's security, including its defenses against malicious code, but it's an ongoing process. Security is pretty meaningless if the service isn't useful for people. We will re-evaluate the dynamics of unfiltered user code again as conditions change. JavaScript can do a lot of amazing things, and believe me, no one wants to see those things more than we do.
The company and 2 other people say
this answers the question
The best answer from everyone
-
Okay I am going to ask/suggest could you please make the html box larger or scalable in the new wiki 2.0?
Thanks
3 people say
this answers the question
-
Inappropriate?It strips directly inserted Javascript, mostly not even because we want to keep people from using it, but because inline javascript on a WYSIWYG editor gets really awkward and may mess with the editing page itself.
The best way to insert Javascript with the 2.0 editor is as an HTML plugin (Insert Plugin -> PBwiki Magic -> HTML). That way, it's only a little plugin box on the editing mode, but will work full-fledged on the real page. -
Inappropriate?Yeah, that "little plugin box" really doesn't make for easy editing of javascript (or anything else, for that matter). -
Inappropriate?Okay I am going to ask/suggest could you please make the html box larger or scalable in the new wiki 2.0?
Thanks
3 people say
this answers the question
-
Inappropriate?This is a great idea. I'll make sure this is seen. -
Inappropriate?The size of the html box actually bothered me, too. It would be nice to have something like a preview pop-up window for optimum view of the page being edited. -
Inappropriate?So is anybody having any luck making JavaScript work in PBwiki 2.0? Maybe I just keep choosing non-supported scripts? -
Inappropriate?If you want us to use the html plugin then you are going to have to increase the capacity from 1000 characters and make it a bit more user-firendly. I'm really not happy that the new 'improved' editor strips out my css and javascript. We need a solution to this.
Seanmac
I’m not happy
-
Inappropriate?CORRECTION
In 2.0 JavaScript is pretty aggressively removed from the page, even if it's put into the HTML plug-in. This is because of the significant security risks JavaScript presents for wikis.
So to be clear, JavaScript should not work on your 2.0 wiki if you paste it into the editor, source, or even the HTML plugin.
The only place that JavaScript should work in 2.0 is through the Custom HTML tool. This will add JavaScript such as analytics tools across all your wiki pages, however it doesn't allow for per-page JavaScript like widgets, forms etc.
2 people say
this answers the question
-
Inappropriate?I notice you have marked this as an "Official Response". So this is the final word from PBwiki? That absolutely no per-page JS will ever be allowed in 2.0? I'd like to make sure, before I publicize this decision to the hundreds of active Widget users who are waiting to find out how severely their day-to-day operations are going to be affected by this decision.
Just for the record, would you care to elaborate on the "significant security risks" you mentioned? Several hundred wikis use JS every day, and have been for years, and I've never heard of a security problem with even one of them. Ever. -
Inappropriate?Ouch! No JavaScript support at all?!? That's not very Web 2.0...
Is there any consideration to change this?
I’m scared!
-
Inappropriate?Here's a free workaround to put arbitrary javascript and CSS code into a 2.0 wiki!
* without having to resort to the wiki-wide (feature to be paid) Custom HTML tool
* on every -single- wiki page.
Choose
1) Insert Plugin
2a) Productivity -> Any Google Gadget or
2b) Video -> YouTube video
3) paste code
4) click Preview
do not mind the preview and click OK
Done!
I’m happy again! ... until they'll break it ...
1 person says
this answers the question
-
-
Inappropriate?My initial delight about being able to add custom css and javascript to the header has been tempered by the announcement that page-by-page scripting is not actively supported and the widget library will become redundant. Ouch, that is not good. I, too, would like a detailed explanantion as to why javascript entered this way is deemed a security risk when entering script into the header is not? I think this discussion thread is evidence enough that this functionality is very important to a lot of users. I don't know how many used the widget library in pbwiki 1.0 but I guess it is a lot. Honestly, I think you should be actively working with your users to come to some constructive resolution rather than users trying to find holes to manipulate like the above work around. It is time to "get real" with your customers - Get Satisfaction mission statement.
Seanmac
-
Inappropriate?"I don't know how many used the widget library in pbwiki 1.0 but I guess it is a lot."
Over 700 when we stopped counting.
-
Inappropriate?Javascript can be used for good or for evil.
Javascript had been turned off for 2.0 test wikis, and I knew there were a lot of you who wanted to test if out, so I made sure Brian turned it on for the duration of the testing period.
However, it WILL be a paid feature once 2.0 is released, and I think the concept of page-specific CSS and Javascript is being tossed around internally as a feature we might roll out later.
I'm sorry about all the confusion that has surrounded this issue. -
Inappropriate?"I made sure Brian turned it on for the duration of the testing period"
Are you referring to the HTML HEAD setting or the embedded ability which has always been available in 1.0 since day 1?
"the concept of page-specific CSS and Javascript is being tossed around internally as a feature we might roll out later"
Actually, you rolled it out two years ago. I know, I've been using it.
There's absolutely no confusion. Just the sound of hundreds of wikis breaking.
I’m really angry that my wiki has been broken with no notice.
-
Inappropriate?"Javascript can be used for good or for evil."
Can you please discuss this more? Lots of Web 2.0 sites use javascript or AJAX and I haven't heard any major discussions about security. I think you're concern about security is a red herring - though for what I can't imagine.
I’m afraid
-
Inappropriate?You've been using it for two years on your 2.0 wiki? That's strange, we've only just released that version for beta testing recently.
Since the topic of this thread is Javascript in 2.0 wikis, I assumed everyone would be talking about javascript in 2.0 wikis. If I were talking about the changes to javascript in 1.0 wikis, I would start a new topic and expound upon them there.
What Brian turned on was Javascript via the Custom HTML feature.
I'm sorry if my trying to make sure you all are updated on the future of javascript in your 2.0 wikis has offended you. Heaven forbid you, your users, know what's going on.
Perhaps you and Paul can talk about this offline. -
Inappropriate?No, you have the wrong idea. I'm not offended in the least. And I have spoken with Paul on multiple occasions about this, and I have not gotten a clear answer from him, either.
The intent of this thread (which I started) was perhaps unclear. (If Get Satisfaction allowed us to update the question, I could have clarified, but it doesn't, so I didn't.) If it helps, I can start a new thread, with the title "Will PBwiki 2.0 support the same Javascript features that have always been freely available in 1.0?". I do apologize if there was any misunderstanding about exactly what I was asking. I hope this clears things up. -
Inappropriate?User - "I think you're concern about security is a red herring - though for what I can't imagine."
PBwiki - "it WILL be a paid feature once 2.0 is released"
Please don't take that quote personally, Ms. Greene. I know that you have nothing to do with these sorts of management decisions - you're just quoting what you've been told. And doing it quite nicely, I might add. :)
I really do not intend to offend you in the slightest. You're just trying to do your job, just like I am trying to keep my wikis functioning, as they have been for the past two years. I can certainly empathize with your position, as it is one that I would not willingly undertake.
I’m hoping this answers sraymond's question
-
Inappropriate?I'm concerned about the page-specific limitation on javascript... so, no, my question isn't answered regarding security concerns.
-
Inappropriate?It's not that we're afraid you, the users who are trying to use PBwiki to the fullest, will implement malicious Javascript. It's people who, in the past, we've had to block and ban because they were using their wikis to spam and spread viruses. We don't have any way of doing background checks on our users to make sure they won't use PBwiki to harm others, and we wouldn't ever want to. That would be absurd, a waste of time, and most importantly, a serious privacy invasion. Way too paranoid for us.
So what we do is put it behind a barrier of money, much like MetaFilter. They charge $5 to create an account, and simply by putting a price on registration, they get rid of a lot of random trolls, spammers, griefers, and other people who generally frequent open forums and the like, just to get a kick out of annoying others.
Similarly, if we have Javascript be a paid feature, we can prevent people who just want to take advantage of PBwikis features from doing as much harm as they could if they were able to utilize Javascript as well.
I'm sure I could be explaining this better. I know other people around the office have found some weird things that happen with Javascript on 2.0 wikis, I'll have one of them pipe in soon. -
Inappropriate?I thought pbwiki 2.0 was the next step in the natural evolution of pbwiki and not the production of a completely different pbwiki platform. The idea that we can't talk about pbwiki 2.0 functionality while directly referring to it predecessor seems ludicrous given that it is expected that all pbwiki 1.0 wiki will migrate to 2.0 eventually. Javascript has always been available in 1.0 and it was not a gross assumption to think that it would be supported in 2.0. Just because you have stuck a 2.0 at the end and improved certain functionality does not mean you can take valuable functionality away from your users with them being unhappy.
I can possibly see the logic in applying a subscription to fend off spamers and the likes but I'd like to know how much of a problem it really is before I accept the justification for money to change hands. I work on evidence and I have not seen much in the way of that yet. The fact that the team skirt round meaty issues like this just fosters a belief that we are being screwed!
Finally, and I'll shut up after this. If you are working on the principle that charging for adding javascript to the header will put spammers off, why not allow page-by-page javascript in the same vein? Maybe there is a technical answer to this which is beyond me but I cannot understand this. Can anyone enlighten me? -
Inappropriate?There are all sorts of evil things you can do with JavaScript, ranging from stealing cookies to redirecting you to unsavory destinations.
The reason the HTML plugin in edit mode is filtered when the Custom HTML is not is because the Custom HTML can only be edited by an admin, someone who is presumably trustworthy. Especially on public wikis, allowing anyone to insert a chunk of random JavaScript would be incredibly dangerous.
As for the “not very Web 2.0” statement, I think you'll find that JavaScript is stripped out pretty much everywhere. JavaScript getting through the cracks means the potential for Cross-Site Scripting attacks, and those are no good.
The bottom line is that we're continually hardening PBwiki 2.0's security, including its defenses against malicious code, but it's an ongoing process. Security is pretty meaningless if the service isn't useful for people. We will re-evaluate the dynamics of unfiltered user code again as conditions change. JavaScript can do a lot of amazing things, and believe me, no one wants to see those things more than we do.
The company and 2 other people say
this answers the question
-
Inappropriate?"The reason the HTML plugin in edit mode is filtered when the Custom HTML is not is because the Custom HTML can only be edited by an admin, someone who is presumably trustworthy."
I hadn't considered that aspect, but it certainly makes the solution quite obvious: don't strip out javascript (or CSS, or anything, for that matter) from the HTML plugin if the Admin is doing the editing. I'm pretty sure you are technically able to determine if I'm the wiki owner at the moment I click 'Save', right?
I would say "for that matter, don't strip it out of the Source View, either", but I'm willing to concede that FCKeditor can't handle some things in the source.
I’m glad we got that worked out.