Antechinus recently committed a change (REV 10827) to add jQuery 1.6.4 minified to SMF. It is a huge change for SMF. We've always written our own code with minor exceptions. Now we're escaping the "not invented here" mentality and using a proven product with a great community. Not only will this increase our development speed for Javascript based method, but it will also give customization writers a boost as well. There's the possibility of speeding up your sites, lessening what needs to be downloaded, and quickly and easily adding more Javascript based features. There's a huge jQuery community with great documentation to help with issues that may come up.

"jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript." -- jQuery.com. It is also free open source software (FOSS) released under a MIT or GPL license which allows us to change and distribute it.

Some places you might find jQuery used: collapsing categories, drag & drop in several places (file attachments, board ordering, menu ordering), menus, quick reply, image viewing with a lightbox, color selectors, anything using AJAX, and possibly a lot more.

We're always looking for people to help us out. So, start gearing up to use jQuery in your customizations and read more about it. Make some good, open source customizations using jQuery and you might get an invite to the Development Team.


If you're interested in helping SMF with jQuery development, see the Bug Reports board.
To learn more about jQuery, see the jQuery website.

Heck yes! jQuery makes life so much easier when it comes to ajax applications and other javascript intensive websites. It shortens the code a lot. I'm also glad to see you guys using it for more than just animations, which are cool, but not worth including a library for.

+1

This is a very exciting update, cracking out the jQuery books!

Just to clear this up: we are allowed to use plugins in our modifications as long as they conform to the license of the plugin?

That should be fine.  As long as the license from the plugin permits redistribution in the license your modification will use, it shouldn't be any trouble.

jQuery is really fantastic. I'm currently exploring it.

More security holes?

Quote from: GravuTrad on March 01, 2012, 01:59:22 PM
More security holes?

huh?

I played with it for a while but decided not to use it.  I was looking at it for security reasons for a challenge page for a  mod I am updating.  Thought it would save some time.  After some research, I discovered that CloudFlare started with JQuery and then stopped using it for unknown security reasons.  Furthermore the JQuery code I saw was client-side and can be manipulated.  Though more difficult to implement, I opted for server-side php sprinkled with some small JS code.

You should never depend on client-side code for security. Always assume that anything the user can touch is insecure and has been altered maliciously.

That being said, using jQuery over regular javascript doesn't add any security holes to your server. You have to have bad server-side code running, and even then you can exploit the same holes in that server-side code with plain old javascript.

Being dependant of other software is always a security risk in more. then more dependances too. That's why unknown woudn't use 3rd party codes...

Everything is a security risk. There is a risk in everything you do. You risk breaking your ankle by taking a step forward, does that stop you from walking?

You are relying on the linux kernel (or the windows one), on the particular distribution you are using (or the particular version of windows), then on apache, mysql/postgre/sqlite, php... am I missing anything? Any of those has (for sure something is there, not yet discovered, but it's there) for sure a more problematic (being server side) security hole than any bug jQuery can have.
IMHO of course.

I think the issue is that jQuery gives you tools that, if you are not careful, you can really open yourself up to XSS attacks which are fired off when a user on your site clicks a malicious link -- on your site. Which is easy to arrange if your site is a forum (or GMail, which is where the vulnerability was first discovered). The malicious site has access to the users' session cookie because it is accessed through the same browser session. It can send an HTTP request for JSON data to your site, that only the victim should be able to use. Like the victim's contact list. Anything the website can serve up can be captured and parsed. Pure JSON-formatted files are especially vulnerable. Since there have been requests for more AJAXy kind of stuff in the future, this could be relevant. The malicious website javascript can then do many things with that data -- email it to a bad guy, for example.

http://www.cvedetails.com/vulnerability-list/vendor_id-6538/product_id-11031/
http://insecureweb.com/javascript/secure-your-ajax-request-with-jquery/

The exploit's discoverer gives 3 ways to combat this type of attack, but discovers there are ways around at least 2 of them.
http://jeremiahgrossman.blogspot.com/2006/01/advanced-web-attack-techniques-using.html

jQuery doesn't give an attacker access to anything more than plain Javascript does. It's that simple. There is no added security risk from jQuery, and there never will be.

Quote from: AngelinaBelle on March 02, 2012, 01:22:32 PM
I think the issue is that jQuery gives you tools that, if you are not careful, you can really open yourself up to XSS attacks

And PHP is worse in that respect if you're not careful with your code, but we still use it. You just have to know how to avoid making those mistakes.

I agree, Fustrate.  It's not JQuery itself that's the danger, directly.  It's the cool things JQuery tempts you to do that  you have to watch out for.  The devil is in the details.

The biggest risk of JQuery is it's popularity.  The exploit effort always increases with popularity.

There are many plugins for JQuery. Some of them are well written and other may not be or are not as complete as they could be...  Good People tend to trust plugins where as bad People like to exploit them.  Maybe we should have SMF approved plugins.

That being said, I do not mind JQuery being added to SMF but I do hesitate with SMF depending on JQuery as it's core to function.  I like to see the heart of the JS for SMF being provided by SMF.

Exactly.

Quote from: butchs on March 03, 2012, 06:54:31 AM
The biggest risk of JQuery is it's popularity.  The exploit effort always increases with popularity.

As far as my knowledge goes for this subject, you just need to ply your utmost attention to the happenings of DOM to control the behavior of JS/JQuery.

Moreover whenever server or permissions sort of things comes into play I always tend to go for server side languages. Languages like JS are best for front end/client side.

So we have to keep a very low profile with SMF in a way that it doesn't become popular enough to be exploited?...

Quote from: Joker™ on March 04, 2012, 07:51:28 AM
Moreover whenever server or permissions sort of things comes into play I always tend to go for server side languages. Languages like JS are best for front end/client side.

Yes. The danger exists when such information is passed to the client side -- like the memberlist, when it is made available for auto-match when you are sending a PM.

The gmail exploit happened because the server passed contact information information to the client-side javascript, so it is available to the user sending email, which is the purpose of gmail. And a piece of javascript malware running in the same browser session could request the contact information in the same way that the legitimate client-side script ordinarily did. And then use that information to send spam to an entire gmail contact list.

The danger in this case is in passing confidential information to the client-side script.

indeed, jquery is a nice product, been using it for a while

Don't re-invent the wheel

Captcha
Editor
Javascript Frameworks

all three things that despite the quality of talent around here, you won't match the FOSS alternatives.

Yup. It's the sensible option, and can be used safely. Lots of sites already use it safely, so there's no reason why SMF cannot.

Quote from: butchs on March 03, 2012, 06:54:31 AM
The biggest risk of JQuery is it's popularity.  The exploit effort always increases with popularity.

There are many plugins for JQuery. Some of them are well written and other may not be or are not as complete as they could be...  Good People tend to trust plugins where as bad People like to exploit them.  Maybe we should have SMF approved plugins.

That being said, I do not mind JQuery being added to SMF but I do hesitate with SMF depending on JQuery as it's core to function.  I like to see the heart of the JS for SMF being provided by SMF.

Theres always Mootools, which is less used, but equally powerful.

But seriously, if SMF uses a javascript framework  doesn't automatically make it vulnerable if there are plugins for it that ARE unsafe. That plugin still have to be added somehow, most likely by a designer etc. and it would not be included in a pure SMF installasion. Its same today really: if a theme use a unsafe javascript right now, its risking SMF in just the same way..but you can't blame SMF for it.

The fact that JQuery is popular makes it more targeted for people finding vulnerabilities, true..but it also have more people making it SAFE. Don't forget that.

It seems to me that we really have no choice since the decision was made some time ago.   

So, now that SMF relies on 3rd part software for it's Javascript, I assume SMF will release a "security" update to coincide with a JQuery update?   

There you go...  have SMF check for jquery updates and download them automatically?     Here is a thought, why not make jquery optional by providing hooks.  If it is installed then the "additional features" are be enabled.  Otherwise, plan jane SMF JS.

The code allows for calling the latest from the Goggle CDN, or from using a local jQuery version of your choice.

Quote from: butchs on April 15, 2012, 06:57:23 PM
It seems to me that we really have no choice since the decision was made some time ago.   

So, now that SMF relies on 3rd part software for it's Javascript, I assume SMF will release a "security" update to coincide with a JQuery update?   

I don't see why we'd have to - you can just update the jQuery version you're serving in the admin area. Or at least you should be able to - I'll poke Spuds about it.

QuoteThere you go...  have SMF check for jquery updates and download them automatically?     Here is a thought, why not make jquery optional by providing hooks.  If it is installed then the "additional features" are be enabled.  Otherwise, plan jane SMF JS.

That would mean writing the javascript twice, which is ridiculous. If you don't want to use jQuery, you'll end up with the same experience as someone who disables javascript, pretty much.

Quote from: Fustrate on April 15, 2012, 09:47:05 PM
I don't see why we'd have to - you can just update the jQuery version you're serving in the admin area. Or at least you should be able to - I'll poke Spuds about it.

This is SMF.  Most admins will not be able to do that.  I do not understand the logic to include 3rd party software that will be minimally supported.

Humm...

Quote from: CodeIgniter User Guide Version 2.1.0CodeIgniter provides a library to help you with certain common functions that you may want to use with Javascript. Please note that CodeIgniter does not require the jQuery library to run, and that any scripting library will work equally well. The jQuery library is simply presented as a convenience if you choose to use it.

I always was under the impression that if an admin wanted to add a 3rd party software it was their responsibility.  Take coppermine for example. I always have to check for the latest update then apply it.  Of course, the programmers do not make it easy.  Their solution is a complete reinstall.  Every now and then (before FF)  I miss an update by a few months and a bad guy will take advantage of it.  Do not get me wrong, I am not dead set against it but, it just seems like another piece of software I have to keep an eye on and maintain.  Bla!  I am lazy at heart... 

Quote from: Fustrate on April 15, 2012, 09:47:05 PM
That would mean writing the javascript twice, which is ridiculous. If you don't want to use jQuery, you'll end up with the same experience as someone who disables javascript, pretty much.

Not interested in disabling js.  More interested in what to do with all those sprinkles.   

My question does SMF really need all the JS that is in it? It seems to be sprinkled all over the banana split.  Sometimes I wish I could have my sprinkles separate... and eat them when I feel like it.  What is going to be done about all those sprinkles?

The sprinkles are all over the place.  Add jQuery is like taking all of them and putting them in once big sprinkle storage container.  Once this is done you need to figgure out an interface.  I thought that things like this were the reason for the development of integration hooks in the first place.  Is this really less work?

Have you even USED jQuery?

jQuery is not a plugin that has to be kept up to date.  In fact, you rarely want to just include the most recent version.  Instead you pick a version and upgrade after you've tested.  At work we were running 1.4 for a few years and are just now updating to 1.7.  Looking at the release notes I don't recall any security releases.  I would expect that SMF would package the jQuery file that was used and tested against.  If jQuery released a minor version that fixed some critical issue then SMF could easily release their own patch for it via the package manager.

What jQuery allows for the devs and themers to write complicated JS a lot better and easier with a greater compatibility between browsers.

Quote from: Thantos on April 16, 2012, 11:00:20 PM
If jQuery released a minor version that fixed some critical issue then SMF could easily release their own patch for it via the package manager.

It isn't really more complicated than that!

Been waiting for this for a long time.

Some mods have jquery bundled with them so those mods should be updated too

well.... all mods would have to be updated for 2.1 anyway....

Quote from: Kindred on October 10, 2012, 06:14:21 PM
well.... all mods would have to be updated for 2.1 anyway....

not all mods need an update...