I would like to show some CM1 widgets (e.g. comment, rating) on html pages when it is logged in. I plan to use server-side includes codes to show/hide the widget.
This approach is to try to AVOID EXPOSING CM1 WIDGET CODES on the html pages so that the user does not know what URL this widget is calling to retrieve or update. This is important for security reason.
The use case is like this:
- When the user does not log in, the CM1 rating widget does not show on any html page.
- After the user log in, the CM1 rating widget will show on all html pages and the user cannot view CM1 widget codes
I welcome the alternate approach if there is a better ones.
Thanks very much!
First, this is not a use case we QA against so there may be some concerns that modifications to widgets down the line might negatively affect this type of deployment. That said, because all CM1 widgets get published out as static HTML containing the required AJAX queries, there’s no reason you can’t grab the source code of a widget from a published page (the source of a page in preview won’t work because previewed pages don’t link up to the DTS server) and relocate this code it into a server-side include that would get injected back into your live HTML.
All widgets are wrapped in a Div using the class “perc-widget”, so they should be pretty easy to track down. Obviously you would want to fully configure the widget in CM1 first before publishing and extracting the code.
Thanks Nathaniel for your prompt reply!
It makes sense with your explanation. I need further assistance on how to fully configure the widget later. So I guess server-side includes approach is not applicable in this case, right?
If the widget code is “exposed”, can the end-user tamper the widget code to cause adverse impact on our website, for example, multiple submissions of bad ratings or comments on our web page?
I’m glad I could clear some of that up. Yes, it would be your call if you think storing the widget code in a server-side include that only gets exposed if a user authenticates (using your own authentication process) would provide worthwhile security benefits.
There’s no CAPTCHA or other type of anti-spam measures built into the Comments / Forms widgets that would prevent bots or mischievous site visitors from spamming your DTS database with junk comments or forms, either through the forms on your site, or directly using a tool such as Poster. That said, in order to do anything worse than loading your server with junk content (update or remove content, for example) you would need to be able to reach your DTS server over HTTPS (it’s common to setup your server topology so that only your CM1 app server can hit your DTS server over the HTTPS port) and know the encrypted DTS manager password.
With these limitations known, it’s worth noting that there are numerous third party plugins that you can implement in CM1 for comments or forms that would provide you with more substantial security, if that’s a major concern of yours.
I will further touch base with you on the enhanced security options later.