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

Change in behavior between 1.6.4 and 1.6.5 for getErrorMessages #151

Closed
mjclemente opened this issue Mar 11, 2022 · 7 comments
Closed

Change in behavior between 1.6.4 and 1.6.5 for getErrorMessages #151

mjclemente opened this issue Mar 11, 2022 · 7 comments

Comments

@mjclemente
Copy link

First - thank you for all the work that goes into Antisamy - really appreciate the active development and work that goes into it!

To begin - I did read the README and understand that getErrorMessages() does not answer the question as to whether input is safe or not. In light of that, you may not care about this change in behavior, but I thought it worth noting.

In version 1.6.4, the following input triggered an error message:

<img
    style="FLOAT: right; MARGIN: 0px 0px 10px 10px; WIDTH: 150px; CURSOR: hand; HEIGHT: 100px" alt=""
    src="http://www.charityadvantage.com/ChildrensmuseumEaston/images/BookswithBill.jpg" border="0" />

Calling getErrorMessages() would return:

The img tag had a style attribute, "CURSOR", that could not be allowed for security reasons.

As of 1.6.5, the message is no longer returned - though to be clear, the cursor property is still removed, as expected.

Is this change expected?

Thanks again!

@davewichers
Copy link
Collaborator

@spassarop - Your thoughts on this?

@spassarop
Copy link
Collaborator

Hi @mjclemente. You're right, a constructor for CssHandler class was added and it was not using the error messages list it had as parameter. The constructor would always create a new empty ArrayList.

The fix is easy so expect to find it fixed for 1.7.0, I'll make the change in a moment.

@davewichers, the change was made in this commit. Do you remember why it was left with an empty list in the first place? I think you asked me to review the changes but I didn't note that.

@davewichers
Copy link
Collaborator

@spassarop - Ii don't recall why. Probably a mistake on my part. If you are going to edit copyright dates, you might as well say its 2022, not 2021 :-)

@spassarop
Copy link
Collaborator

Date edited on test file

@davewichers
Copy link
Collaborator

@mjclemente - Thanks for reporting this. This will be fixed in the 1.7.0 release.

@mjclemente
Copy link
Author

@davewichers awesome!

Glad that it was helpful, and thanks so much!

@davewichers
Copy link
Collaborator

Fix included in v1.6.6 release.

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

No branches or pull requests

3 participants