We like to add HTML-layout to eMail messages as send by DSpace. Simple adding HTML-tags to one of the eMail templates as 'subscription' does not work.
I suppose we have to do some Java programming, but I have no idea where to start.
Does anyone of you has experience with HTML in DSpace eMails?
Adding HTML tags in the EMail can be done, but this requires some changes to the default EMail class.
It consists of the following changes:
When setting the text on the actual message sent, an additional subType can be added (Check : https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/core/Email.java#L293). By default this takes a text and the charset, but has an additional "subType". Setting this to "html" enables the message to properly check for tags.
In the "EMail" class, you could add an additional "subType" variable which defaults to "plain" for example, and can be overwritten through a setter. (I'd refrain from simply setting it to html for every email template as the checking for existing tags might break other templates and also take some extra time).
The actual code that calls the "subscription" template can then create the mail and set the subtype properly.
See example images for the difference between the "plain" and "html" subtype.
"plain" subtype vs "html" subtype
Related
We currently use wysihtml5-rails to let our users edit emails before they are sent but this is not working out so well for a few reasons.
I need the comments to allow for Outlook specific comments like these . All comments are being removed, currently.
I also need the CSS classes to be untouched as the editor content will be a pre-generated email that includes CSS classes. Our editor will only keep classes that are whitelisted but this is annoying as we need to update that list with every change.
Same goes for inline styles. Some of the styles in the generated email are inline instead of in classes. Those need to be kept but they are being removed.
Is there any way I can get our editor to work this way?
I found a solution but it's hacky.
I realized that the raw HTML was being stored on the page in a hidden textarea tag. Interestingly, all the elements that I needed (CSS classes, comments) were still there. But when submitting the form, the value of this textarea was replaced with the parsed results from the editor which gets sent to the server. All the comments and classes are gone from this text.
The solution was then to create a second field that takes the unparsed value from the WYSIWYG editor and sends that along. Easy in rails but just making this new field part of a form. Then the controller can choose which value to take. In my case, I renamed the existing message field to parsed_message. Then added a new message field which will hold the unparsed message.
The WYSIWYG editor we are using allows this by having a method that can be called at any time: window.email_editor.getValue(). Here the email_editor is the editor instantiated by the javascript on the page.
I'm checking some markup for an app we're working on, and one of the wakanda-generated meta tags fails the W3C validation.
<meta name="WAF.packageJson">
The validation service is stating that the "Element 'meta' is missing one or more of the following attributes: content, property."
I am considering setting an arbitrary value for 'content' to pass the validation, but was wondering if there is a better way to do this for these particular tags?
That's the WD2 migration meta tag. It's added by default to your Pages to indicate that the Page be delivered using Wakanda WD2.
The correct solution is either remove it either fill it with dummy data. I suggest the latter.
If this meta tag is present, a package.json file is created and maintained for the Page. This file contains the page's dependencies, which are all the files that Wakanda Server needs to send over with the page when it is requested.
If you want to specify a specific package.json file, you can do so by specifying it in the content parameter:
If you want to disable the WD2 for one of your Pages, you can either remove the tag or modify its name so that WD2 does not find the "WAF.packageJson" name property in the Page.
You can find more information regarding this in the package.json doc and on the html page doc
From W3Schools:
The content attribute MUST be defined if the name or the http-equiv attribute is defined. If none of these are defined, the content attribute CANNOT be defined.
The content attribute IS required here, there may but should be no workaround for this in the validation. You will need to add a content for your <meta>-tags.
I am volunteering on a website-based project that is trying to make all pages fully operable JavaScript free before adding any JavaScript for enhancements, and I was asked to investigate whether or not a particular scenario could be handled purely through HTML/CSS.
What we have is a form that is populated to help us filter a list of tickets that are displayed on the screen after a page update through a GET action, which itself works fine, but the concern with the current implementation is that the URL cannot be made into a permanent link. The request, however, to keep the permanent link as minimal as possible, is to only send GET parameters for fields that are populated with something (so, suppressing GET parameters for fields that are blank) instead of having a different GET parameter for each form field on the page.
I have thought of several ways that could be done, most including JavaScript (example: create fields with ids but no names and a hidden field w/ name that uses JS to grab the data from the fields), but also one that would be a POST action with a redirect back to the GET with a human readable string that could be permanently used. The lead dev, however would prefer not to go through the POST/redirect method if at all possible.
That being said, I'm trying to make sure I cover all my bases and ask experts their thoughts on this before I strongly push for the POST/redirect solution: Is there a way using only HTML & CSS to directly suppress GET parameters of a form for fields that are blank without using a POST/redirect?
No, suppressing fields from being submitted in an HTML form with method of "GET" is not possible without using JavaScript, or instead submitting the form with a POST method and using a server side function to minimize the form.
What fields are submitted are defined by the HTML specification and HTML and CSS alone cannot modify this behavior and still have the browser be compliant with the standards.
No, you cannot programmatically suppress any default browser behavior without using some kind of client scripting language, like JavaScript.
As a side note, you say "JavaScript for enhancements", but JavaScript is not used for enhancements these days. And no one in the real world would except a decent front-end without the use of JavaScript. I would suggest you simply use JavaScript.
I do not think you can avoid Javascript here to pre process before submission to eliminate unchanged /empty form fields.
I know similar questions have already been asked but the answer is almost always the same: you need to share the image on a server and link to it from within the email.
For my purpose I cannot do that.
The image needs to be personalized for each user I send an email to (so the email will be dynamically generated for each user and will not always be the same. I cannot share the image -- since it will change but also for avoiding disclosure of users' information).
Have you ever encountered this scenario? Should I go with attachments or base64 encoding of images? Thoughts/experiences?
The HTML body must refer to the images using the content id (cid): <img src="cid:xyz">, where xyz is the value of the attachment content id (Content-ID) MIME header.
If you are creating the message directly in the MIME format, make sure the attachment is added to the message and its Content-ID MIME header is properly set. If you are Outlook Object Model or MAPI, you must set the PR_ATTACH_CONTENT_ID property on the image.
Since HTML5 allows base64 encoded images inline, this might be the easiest way to go. Check the following source: http://www.bigfastblog.com/embed-base64-encoded-images-inline-in-html
You should consider that not all mail clients might support HTML5 and therefore attaching the image and referencing it in your code may be the harder but better choice. Unfortunately I have no experience with that.
Edit: This tutorial looks promising, but I have not tried it: http://www.phpeveryday.com/articles/PHP-Email-Using-Embedded-Images-in-HTML-Email-P113.html
I need to fix XSS issues in my application. Now I am new to JSON and XSS. I think of two ways attacks can happen - first is through html input controls (text boxe/area etc) or through request parameters which are visible in the url (GET). Please suggest if i am missing something here?
I am thinking to use AntiSamy (https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project). I am thinking of creating a custom tag which would contain the value of html controls e.g.
<input type="text" NAME="name" value="<mytag:xssclean><c:out value= escapeXml="false"/></mytag:xssclean>
this tag class would actually use antisamy to scan the html content. will this take care of encoding any malicious javascript content entered into text box/area before sending those parameters to controller classes and then eventually to database? Or would it only encode the content which is coming from controller classes to get rendered on jsp?
Is this the right approach? When would i need to validate on the java side (controller classes by direct validation using antisamy) versus on jsp (with new tag)?
Additionally I have many jsp's which do not have direct form fields with html controls but their struture is created dynamically and jason string is given to the jsp. jsp would simply have : where 'value' would contain the final jason to be rendered on html (including html fields). Do we need to apply XSS solution using antisamy on jason strings or jason data is already safe from XSS attacks and the thing like are already present as text in jason? where should i resolve this issue for json cases?