Can we use JS on sheets?

I am assuming not because of the limitation on jQuery? I would like to use some conditional logic on my sheets to check all the skill boxes that belong to class x when class x is selected in selection field A.

No, you cannot use JavaScript on the character sheets. This has nothing to do with jQuery.

Oh. I see.

It has to do with security considerations I think. Although it would be nice if we were allowed to use some limited js functions. Like the ones used for creating check boxes that tell roll 20 to add the roll to the character action bar. Or to count the number of attacks being made by a weapon and repeat a section of code to dynamically add the correct number of attacks. Or even better, to be able to properly access repeating sections more reliably. I don't suggest they give us full support, just some convenience functionality.

Considering we're using Git as our version control, the only reason I can think of to not let us use JS is that the overhead that comes with it would put the dev team behind on their other tasks. I would imagine that they could find potential security compromises in sheets if they were looking through and testing them, but again that's asking a lot of a small dev team.

Also keep in mind for security considerations that Git is just for the community library. A Mentor with ill intent could make a custom sheet with JS and cause problems.

Yea, that sucks. I just wanted to take some of the pain out of making a character.

Kevin said: Also keep in mind for security considerations that Git is just for the community library. A Mentor with ill intent could make a custom sheet with JS and cause problems. I didn't even think about it that way. Good point.

Mentor or otherwise, as a GM (or probably even a player), I can easily say 'hey guys, the setting document is here , go check it out'. In theory, there is nothing I can do via JS which can cause serious issues for them. I could fork-bomb their browser, which will freeze it for a minute or so, then the kill-script window will pop up and they can fix it. I can log them out of the campaign by closing the tab. I can possibly mess with their account, since it is all hosted by app.roll20... Put the tabletop at some other url and the cross-site scripting prevention in every modern browser would prevent me from doing that even. If the browser JS sandbox is compromised, we've got much bigger issues than roll20. Since they don't support IE, they could allow client-side JS and all it would do is let GMs be jerks without conning their players into following links, but that isn't really an issue. In addition, if the client-side JS is available to mentors only, I have a vested interest not to get banned from the site by putting malware on the sheets, even if it is just fork-bombs and the like. Oh, and I may provide a link like this , and include the noxious js there, which almost certainly could be used to do anything to their account since cross site scripting wouldn't catch it. If anything, that is more likely to work if the players are used to getting weird links because client-side js doesn't work. Bottom line, the security concerns are not significant, the people who can use custom sheets are reasonably accountable, and those bent on screwing their players will still be able to do so. Oh, and don't click on links you haven't inspected to see where they lead. Edit: So looks like their forum code semi-prevents the javascript:stuff link, so I'd have to tell the players to go to a different page and then bookmark a javascript link, come back to the tabletop and go to it. Would be less likely to work, but would catch the foolish...

Logan P. said: Mentor or otherwise, as a GM (or probably even a player), I can easily say 'hey guys, the setting document is here , go check it out'. In theory, there is nothing I can do via JS which can cause serious issues for them. I could fork-bomb their browser, which will freeze it for a minute or so, then the kill-script window will pop up and they can fix it. I can log them out of the campaign by closing the tab. I can possibly mess with their account, since it is all hosted by app.roll20... Put the tabletop at some other url and the cross-site scripting prevention in every modern browser would prevent me from doing that even. If the browser JS sandbox is compromised, we've got much bigger issues than roll20. Since they don't support IE, they could allow client-side JS and all it would do is let GMs be jerks without conning their players into following links, but that isn't really an issue. In addition, if the client-side JS is available to mentors only, I have a vested interest not to get banned from the site by putting malware on the sheets, even if it is just fork-bombs and the like. Oh, and I may provide a link like this , and include the noxious js there, which almost certainly could be used to do anything to their account since cross site scripting wouldn't catch it. If anything, that is more likely to work if the players are used to getting weird links because client-side js doesn't work. Bottom line, the security concerns are not significant, the people who can use custom sheets are reasonably accountable, and those bent on screwing their players will still be able to do so. Oh, and don't click on links you haven't inspected to see where they lead. Edit: So looks like their forum code semi-prevents the javascript:stuff link, so I'd have to tell the players to go to a different page and then bookmark a javascript link, come back to the tabletop and go to it. Would be less likely to work, but would catch the foolish... Well lets see ... with js I could do some of the stuff I messed around with when we had full client side access at the start of the API, you could make it so it looks like the user has been logged out, you could redirect links to sites/servers infected with malicious software or malware.

Alex L. said: Logan P. said: Mentor or otherwise, as a GM (or probably even a player), I can easily say 'hey guys, the setting document is here , go check it out'. In theory, there is nothing I can do via JS which can cause serious issues for them. I could fork-bomb their browser, which will freeze it for a minute or so, then the kill-script window will pop up and they can fix it. I can log them out of the campaign by closing the tab. I can possibly mess with their account, since it is all hosted by app.roll20... Put the tabletop at some other url and the cross-site scripting prevention in every modern browser would prevent me from doing that even. If the browser JS sandbox is compromised, we've got much bigger issues than roll20. Since they don't support IE, they could allow client-side JS and all it would do is let GMs be jerks without conning their players into following links, but that isn't really an issue. In addition, if the client-side JS is available to mentors only, I have a vested interest not to get banned from the site by putting malware on the sheets, even if it is just fork-bombs and the like. Oh, and I may provide a link like this , and include the noxious js there, which almost certainly could be used to do anything to their account since cross site scripting wouldn't catch it. If anything, that is more likely to work if the players are used to getting weird links because client-side js doesn't work. Bottom line, the security concerns are not significant, the people who can use custom sheets are reasonably accountable, and those bent on screwing their players will still be able to do so. Oh, and don't click on links you haven't inspected to see where they lead. Edit: So looks like their forum code semi-prevents the javascript:stuff link, so I'd have to tell the players to go to a different page and then bookmark a javascript link, come back to the tabletop and go to it. Would be less likely to work, but would catch the foolish... Well lets see ... with js I could do some of the stuff I messed around with when we had full client side access at the start of the API, you could make it so it looks like the user has been logged out, you could redirect links to sites/servers infected with malicious software or malware. Right, but my point is that you can still do that. Making it look like they've logged out isn't likely, but wouldn't be a big deal anyway. You hose my client, I log in again, fetch the malicious js file and post it to the forums, explaining exactly what happened. Since it isn't permanent damage, all it will do is ruin your reputation. Like I said, if client-side js was allowed, the tabletop would need to be hosted off a different subdomain to prevent cross-site attacks (with everything hosted off of app.roll20.net, I could delete your account with client-side js). The malware download site still is trivial, if you post a tinyurl link, and claim it is something they will need, how likely are they to not follow it? The way I would handle it if I were running things would be via signed javascript. Firefox has support built in for it, for handling expanded access in scripts; but it'd be pretty simple with something like roll20 to implement it cross-browser. The idea is that before the client-side js is loaded, it is presented to the user for verification, and then cached. If changes are made, it requires reapproval. Since the author information is embedded in the script, and a short signature is provided, you'd be able to have good scripts listed on the forum, which could be easily reviewed by the community, shifting the burden of determining if the script is okay away from the players. If you want to allow minor modification, simply add a diff utility; so that a DM could start from a basic community script and change settings as needed and it would show the players the basic script and highlight what's been changed. This is similar to the firefox extension I wrote for roll20, except that it allows automatic updates and ensures the person adding it has the scripts at least presented to them. I don't think it is unreasonable to require players to take responsibility for this kind of thing. Especially since there isn't really anything that can be done client-side via js that can't be done manually, so if the player hits the reject button, they may be at a disadvantage, but they'd still be able to do pretty much everything.