I am developing my own semantic web-accessible jquery accordion plugin. I observe other popular plugins and found an issue in JqueryUi accordion plugin. In its example header role is changed to "tab". So the result is h3 element with role attr "tab". But I noticed for several times that changing the native role is non conforming. Me resource is https://specs.webplatform.org/html-aria/webspecs/master/ and the main quote is: "Web developers must not use the ARIA role and aria-* attributes in a manner that conflicts with the semantics described in the Document conformance requirements for use of ARIA attributes in HTML table."
So, jQueryUi is not valid?
That is not correct. As can be read in the 1.1 version of the spec http://www.w3.org/TR/wai-aria-1.1/#h-host_general_conflict the host semantics can be overridden and the ARIA role takes precedence (MUST).
When a WAI-ARIA role is provided, user agents must use the semantic of the
WAI-ARIA role for processing, not the native semantic, unless the role
requires WAI-ARIA states and properties whose attributes are explicitly
forbidden on the native element by the host language.
Because there is no native tab role in HTML, it would be reasonable to conclude that it even meets the SHOULD portions of ARIA (but this is more open to interpretation)
Related
In the Swagger Editor example, http://editor.swagger.io/#/, there is a "Models" section later on in the rendered document after the endpoints are shown. Is this only a feature of this editor to see how things are looking at you define them, or is this also possible to display all models in Swagger UI?
(It would be really great if they could be also displayed outside of the endpoint information, especially for models that are defined but not used yet...so collaborators can see what's coming.)
According to https://github.com/swagger-api/swagger-ui/issues/1052 this is now part of 3.0.
I have a site which allows an admin to edit a section of one page of the site with arbitrary HTML (via a WSYWIG editor), and I want to figure out a way to serve this arbitrary HTML securely to other users.
The basic intent is to eliminate any possibility of XSS errors (i.e, a user getting their cookie stolen or something).I've seen that the following subset of HTML tags are unsafe to allow users to enter: iframe, frame, embed, style, video, object, etc.However, filtering out iFrames or style tags is not feasible for my use case because admins need to be able to upload youtube videos and style the text.
I've also heard that Content Management Systems sometimes serve user-uploaded content from a separate domain (e.g, content.mysite.com) so that whatever code may run as a result of the user-uploaded content can't steal my site's cookie (e.g, app.mysite.com) because of the same origin policy.However, this seems like kind of an overblown solution for me since my site is not a CMS,there's just one part of one page (editable only by admins) which allows for arbitrary customization.
So, is there a way to go about this?Would embedding the arbitrary content in an iframe keep users safe? Thanks in advance!
Also of potential relevance: the framework I'm using is Ruby on Rails.
An html editor on the client is not straightforward to protect against XSS at all. As you say, serving such content from a different domain may mitigate the risk, but gives way to other questions (like for example how will you authenticate and authorize users on the other domain to prevent downloading any user's content).
Also whitelist validation of tags and attributes is usually not feasible. You could have a whitelist of tags and attributes of those tags and anything else could be removed from html code. The problem with this is that the html editor will most likely want to use the style attribute, and styles are vulnerable to XSS, at least in older browsers. An editor usually needs to be able to save a link (<a href="">), and that's also vulnerable to XSS, for example <a href="javascript: alert(1)">.
One approach you may take and one that actually works is Google Caja. It can remove all Javascript from HTML, Javascript and CSS so that it's safe to include in your page. It also has a client-side sanitizer written in Javascript that can be used by itself, and may provide enough protection. Another client-side sanitizer is DOMPurify. Caja at its best is a server-side solution too, but that's somewhat harder to install and maintain. The client-side part of it, and also DOMPurify are slightly less secure as they are all on the client, but can very well provide adequate protection in many situations. (Note that DOMPurify does not work in older browsers and does not sanitize CSS code, which is OK-ish for recent browsers.)
With these client-side solutions, you let the user save any HTML with any injected Javascript to the database if the user (attacker) is smart enough, but when displaying the html content, you send it to the client in a way that's not vulnerable to XSS (like for example in an AJAX response with a text/javascript content type), and then run it through the client-side sanitizer in the browser before inserting into the page DOM (giving it to the editor control itself).
If your editor allows for the right hooks, you can also do this for any preview functionality, sanitizing the HTML entered before switching to preview. This is important, because while arguably a smaller risk, it is still considered XSS if the user can inject Javascript in the editor and then run it in preview, without ever sending it to the server. This is called DOM XSS, and it is one reason you may want to do sanitization on the client.
I am new to Umbraco and was wondering what is the best approach to organize content structure to include pieces of dynamicly added blocks on a site. Let's say I have services section on my home page, and there are service item blocks which are dynamicly added/deleted by the content editor through the backoffice. So where do I actually create this services folder, and service items? It must be also taken into consideration that I am developing multilanguage website.
The question is pretty much similiar to this one in the umbraco-forum , but because I develop for multilang, I find it inconvienet to create any other nodes (for settings or these blocks) on the root level, because they will have to be copied to other languages.
So far I think of three ways to do this:
Create services and service item document types, and include them under the Home page node. The disadvantage of this approch is the confusion between "real pages" and this kind of blocks. (though the workaround could be prefixing the name of "data/block" folder with underscore sign, e.g. "_Services")
Create differents folders for "Pages" and for "Blocks" under under Home page node. Then I could use Url rewriting to overcome extra part which are added in the paths for pages. (so for example map "/pages/about-us" to "/about-us"
Use media types for this kind of blocks. About this I am not sure at all, because I see no option to copy items for other languages as it is done in document types.
The Umbraco resource refers to canvas, which is a feature that allows a content editor to modify content on a page in a WYSIWYG editor style. Canvas is unreliable & has been disowned as buggy & not to be used even on the Umbraco training courses.
You could build a back-office function in a custom datatype (http://umbraco.com/help-and-support/video-tutorials/developing-with-umbraco/data-editors/creating-a-custom-datatype-using-the-usercontrol-wrapper) that mimicked a WYSIWYG editor, but I don't think one currently exists.
The usually pattern when you want blocks of functionality in Umbraco is to use macros. Macro are maintained under the developer section, rather than the content section.
You could also use base extensions (http://our.umbraco.org/wiki/reference/umbraco-base) for dyanmically generated blocks that use Umbraco data.
Whether using a macro or /base you could use some hide/show fields in the affected doc types to show or hide specific blocks on specific pages.
The Spring Security UI plugin, among other things, provides a registration page. On this page are 4 fields: username, email, password, and verify-password. It uses a regular architecture of controller and gsps. Staying with a single page registration for the user, I need to add a bunch of fields -- e.g. address, payment info, etc.
Any thoughts / recommendations on how to extend this plugin's page, so that I can get updated versions and incorporate them without too much re-integration. It's almost like one part of the page should go to the UI controller, and the other parts of the page should go to my controller. Note the UI controller usees regular forms (i.e. not ajax).
Thanks
To custom configure the Spring Security UI plugin I'd first of all have a look at the existing plugin code to get a handle on how it works and then run the override scripts that you require as detailed at:
http://burtbeckwith.github.com/grails-spring-security-ui/docs/manual/guide/10%20Customization.html
In your case you'd need:
grails s2ui-override register com.my.packagename
Jim.
Assuming you used the s2-quickstart script to create the domain classes, controllers, and GSPs, you have 2 options for customising the User domain class
add your custom properties (address, payment info, etc.) directly to the User domain class created by the plugin
create your own User domain class that extends the one generated by the plugin. Add your custom properties to the subclass
According to this article, the latter approach is preferable because:
because it allows you to easily update the generated user domain class
if its template ever changes. It also means you don't overly pollute
your domain model with Spring Security specifics. On the downside, you
have to deal with domain class inheritance, although the cost is
pretty minimal.
You'll also need to add the custom fields to the GSPs. The controller actions probably won't require any modifications.
I'm using Ruby on Rails for an internal site. Different users of the site have access to a wide variety of data and highly disparate perspectives of the data. Within those different classes of users, there needs to be levels of access. Within the levels of access I need to be able to add features from other classes of users.
In the released "Version 1.0" of the intranet site I have implemented the general classes of users. I am now needed to implement much finer-grained control of a users access.
The question is how?
What is the generally accepted practice for coding up user preferences (display the map (or not); access to this feature, but not this feature) without exploding the database schema and populating the view code with <% if feature_allowed %> tags everywhere.
Another totally different approach would be to use acts_as_authenticated and authorization plugins. The tables will be built by the plugins (ie users, roles and roles_users). From the doc:
The authorization plugin provides the following:
A simple way of checking authorization at either the class or instance method
level using #permit and #permit?
Authorization using roles for the entire application, a model class, or an
instance of a model (i.e., a particular object).
Some english-like dynamic methods that draw on the defined roles. You will be
able to use methods like "user.is_fan_of angelina" or "angelina.has_fans?",
where a 'fan' is only defined in the roles table.
Pick-and-choose a mixin for your desired level of database complexity. For
all the features, you will want to use "object roles table" (see below)
populating the view code with <% if
feature_allowed %> tags everywhere.
I don't think you want to do that. Assuming none of the alternatives suggested are practicable, at the very least you should consider shifting those checks into your controllers, where you can refactor them into a before_filter.
See section 11.3 in "Agile Web Development With Rails" (page 158 in my copy of the 2nd edition) where they do exactly that.