Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: limit scope of TeX macro definitions #186

Closed
vyznev opened this issue Dec 28, 2011 · 6 comments
Closed

Feature request: limit scope of TeX macro definitions #186

vyznev opened this issue Dec 28, 2011 · 6 comments

Comments

@vyznev
Copy link

vyznev commented Dec 28, 2011

We're seeing some problems with MathJax's handling of TeX macros (\def, \newcommand, etc.) on math.stackexchange.com. Basically, there are two issues:

  • Typical StackExchange pages include many posts and comments written by several users. Since macro definitions are global to the entire page, macros defined in one post leak out to all subsequent posts on the page.
  • The StackExchange software also features a live preview of posts. This works reasonably well with MathJax in general (although it does have occasional performance issues with long posts), but a problem is that, if one accidentally redefines a standard LaTeX command while typing a post, the definition lingers and there's no easy way to reset it. See this meta thread for an example.

I realize that these issues basically arise from the way we're using MathJax on math.SE, and that an obvious solution would be to "stop doing that, then". However, this is not as practical as it sounds: StackExchange websites are fundamentally collaborative, so having a mixture of content from multiple authors on a page is unavoidable. The live preview is also a standard StackExchange feature, and an extremely convenient one too. I doubt most users would be willing to give it up. I suppose we could disable MathJax parsing in the live preview, but the lack of feedback would make writing LaTeX formulas much more difficult.

I suppose one solution would be to just disable macro definitions (e.g. by redefining \def et al. themselves) on math.SE, but I'd hesitate to do that, since clearly some of our users do find this feature useful (even if most probably aren't even aware of it). What I'd prefer to see would be some features in MathJax to limit the scope of the definitions. As I suggested in the meta.math.SE discussion, that would mean either:

  • some way to save the macro definitions before a Typeset call and to roll them back afterwards, or
  • some way (e.g. a specific class name) to mark an HTML element so that TeX macros defined inside it don't leak outside.

I suppose either of these features would be good enough for us: if we had the latter, we could wrap our posts and preview panes in such HTML elements, while if we had the former, we could implement the latter manually by finding all such elements on the page and typesetting them one by one. (We don't really need nested scopes, although it's an obvious generalization of the second feature.)

Ps. If MathJax already has some way to achieve what I've described above, please let us know (and sorry for bothering you, if that's the case).

@dpvc
Copy link
Member

dpvc commented Dec 28, 2011

I understand the need for what you are asking for, and would not tell you to stop what you are doing (I think the StackExchange model is a really interesting one).

There is a solution included in v2.0 that allows for localized macro definitions. I have added two (non-standard) macros, \begingroup and \endgroup that act as delimiters for local macro definitions. So if your CMS could add \(\begingroup\) at the beginning of each post and \(\endgroup\) at the end of each post (and similarly for the preview) then the definitions included within the post would not leak outside. These can be nested, so using \begingroup while a previous \begingroup is active is OK.

This is new in v2.0, so you can't use it in v1.1, but you can try it out using the v2.0-candidate branch of my fork of MathJax. You can try it out using http://devel.mathjax.org/mathjax/dpvc/v2.0-candidate/MathJax.js if you want, but please don't use that server for a production site.

Davide

@dpvc
Copy link
Member

dpvc commented Dec 28, 2011

PS, version 2.0 has some important performance improvements, particularly for IE, so I think you will find that the results for longer posts are better in this version.

@Menci
Copy link

Menci commented Mar 24, 2019

What if a malicious user write this:

<!-- $\begingroup$ inserted here -->

$\endgroup$

$\renewcommand\frac\textrm{Security Issues}$

$\begingroup$

<!-- $\endgroup$ inserted here -->

@dpvc
Copy link
Member

dpvc commented Mar 24, 2019

@Menci, There are no security issues involved, here, and if there were, there would be no need to use \endgroup to access them. The issue is whether posts in one part of the page should have their macros affect other posts that appear below it on the page. The \begingroup/\endgroup mechanism is intended to limit that, but it is not a perfect solution either. Easier than your example would be to just use \gdef or \global\let. More robust solutions based on this approach are possible, and have been discussed elsewhere; but since StackExchange never did implement this idea (unless they have don it recently), the issue is really rather moot.

@Menci
Copy link

Menci commented Mar 24, 2019

I think there needs to be a way to completely isolate every 'document' in a single webpage to prevent one from affecting the following. Bigger issue is in MathJax-Node and mathjax-node-page than in browser -- if a server runs MathJax with Node.js to serve rendered documents, a malicious input can affect all following requests.

And, where can I find 'more robust solutions' you mentioned?

@dpvc
Copy link
Member

dpvc commented Mar 25, 2019

where can I find 'more robust solutions' you mentioned?

One discussion is here in particular this comment and the code it links to, and another (that I see you already have seen) is here, where I will provide an extension that may be what you are looking for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants