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

Safelist - make is* methods public? #1780

Closed
snak3b1te opened this issue May 26, 2022 · 6 comments
Closed

Safelist - make is* methods public? #1780

snak3b1te opened this issue May 26, 2022 · 6 comments
Milestone

Comments

@snak3b1te
Copy link

I had the problem to verify complete HTML documents and provide detailed reporting on offending tags. No problem - just write a new Cleaner implementation with the changed behavior I thought. Well, not so much: Safelist cannot be used in that scenario because all test methods like #isSafeTag() and friends (#isSafeAttribute(), #getEnforcedAttributes()) are protected or default.
Cleaner can access them of course, being in the same package.
With the Java-9+ module system however, I cannot just create my own class in that same package as it belongs to a different module.
So, I have to write my own Safelist, too. (Or copy the source to some local package.) Which is kind of sad.
Could we make those test methods public so that Safelist could be used in custom code?

@susJohnny
Copy link

The public methods are added instead of modified, #isSafeTag() to be #testSafeTag(), #isSafeAttribute() to be #testSafeAttribute(), #getEnforcedAttributes() to be #enforcedAttributes()

@snak3b1te
Copy link
Author

Brilliant! Thanks a lot.
You may want to consider renaming #testValidProtocol() for consistency to something else - it is currently private but could be mistaken for "one of the test methods". However, I don't see a benefit in making it accessible. As it doesn't show in the API doc. it might be pointless to change it, though.

@jhy
Copy link
Owner

jhy commented Jun 13, 2022

Wouldn't it be better to make the methods only protected? So they can be overridden by extending classes outside of the package. They only make sense in the context of an extending class.

BTW, would @snak3b1te, I would be interested to know what your implementation of isSafeTag is - what extra functionality are you doing? Is it something that would be useful to add to the core jsoup?

@snak3b1te
Copy link
Author

@jhy my interest was to create a custom cleaner. The cleaner needs access to the Safelist's methods to check tags to be safe. With protected they are not accessible from outside the package. I had no intention to change the behavior of Safelist, so no point in inheriting or overriding (IIRC cannot change visibility when overriding).
My cleaner differs from Jsoup's in that it can validate / sanitize complete documents (ie <head/> and <body/>) and that I return some XPath-like expression for invalid tags. I recon that this is rather specific for my use case and does not belong into the core.

@snak3b1te
Copy link
Author

@jhy wanted to check back on the status of this request (as of version 1.16.1). With the Safelist.is* methods protected I can work around by extending Safelist and leaking access to the methods under a different name (not pretty though). Unfortunately, access to the enforced attributes is default i.e., accessible only from the same package. So, no dice. Still need to copy the class :-(

Another thing that bugs me: All methods to create or modify Safelists are public - only when you want to use it, that is all hidden away.

So, while my use case might be rather specific, it would allow re-use of the Safelist class, if those three (#isTagSafe(), #isAttributeSafe(), #getEnforcedAttributes()) methods would be accessible. It would allow to implement custom checkers and cleaners.

@jhy jhy closed this as completed in 8a59792 Oct 18, 2023
@jhy jhy added this to the 1.16.2 milestone Oct 18, 2023
@jhy
Copy link
Owner

jhy commented Oct 18, 2023

Thanks for the feedback - have made those three public.

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