I like to modify (by subclassing) the Plone SecurityPolicy (I like to introduce negative permissions but that is not the point of my question) and find no way in doing so.
There is a property in etc/site.zcml called securityPolicy pointing to AccessControl.security.SecurityPolicy. But nether that class nor its ancestor is called. Instead AccessControl.ImplPython.ZopeSecurityPolicy is called by the cImplementation when checking for security. There is a lame comment on that in the code but not more.
If one changes etc/site.zcml and points it to a custom SecurityPolicy the policy is registered in the global variable _defaultPolicy but in effect nothing changed. Also a call to setSecurityPolicy (e.g. triggered by a zope.processlifetime.IProcessStarting) changes the global but with no effect.
So the question still stands out: Howto modify the Plone SecurityPolicy?
Please no recommendations and discussion on WHY I like to change the security policy and if it is necessary. I have grown up with the zope3 security system and like to have more of it in plone. Just give me a handle.
Related
For HTTP Feature-Policy header you can set the features mentioned in https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy individually. But how can I set a default?
You can do it for Content-Security-Policy by setting default-src, is there an equivalent for Feature-Policy?
It would be more convenient than setting each of the numerous features individually, especially because you'll have to keep that list up to date as new features are added.
There is an active discussion of this issue here:
https://github.com/w3c/webappsec-feature-policy/issues/189
Summarising the github thread, the main issue with having a default policy is that you might be using a feature that later becomes subject to a policy. Your website will then break, and as a result, browser vendors will either not ship the new feature or will be unwilling to make it subject to a policy, and feature policy as a concept will be dead in the water.
There are a number of possible solutions to this:
Make default refer not just to all the existing policies, but everything that might be subject to a policy, by throwing the net incredibly wide. This would disable virtually all DOM, browser and network APIs. But it seems likely that you'd want to use some of this stuff, making the directive pretty useless.
Don't implement default but add some immutable 'bundle' policies. When you adopt the bundle, you know what it is contains, and that won't change, but as new policies are introduced, we can create new larger, more restrictive bundles, without breaking sites that have adopted the previous bundles. This is my suggestion
What would be a proper way to handle global "settings" in my sailsjs application? The user will want to change those settings via the web front of my app.
I imagine I could use a new model "GlobalSettings" with only one item, but I don't really know if it's a good "MVC" practice.
Since it is based on user input, it has to be stored in a database and therefore storing it in model seems like a right choice to me.
Having just 1 row/collection is completely ok in my opinion, especially in the no-SQL field. But for more reusability and scalability, you might want to consider to actually store each setting in invididual row, that might give you space to expand the usability of it in the future.
In my own opinion, I always find as a web app develops, you will start to realize there are more and more fields that you want the user to setup as their preference, as a good practice to relax the application.
For me I usually setup a meta_data model with name, value, criteria, and some other fields.
For example, when viewing your web page, 'Alice' may want a background color of black, 'Bob' may want a background color of green. Then you can let them modify or insert row into this meta_data collection. Then in your database, you will have
name value criteria
background_color black user_name='Alice'
background_color green user_name='Bob'
and it can be all kinds of values.
of course if you just have one value that can be changed by all of your users, it is probably a good idea to know who updated them. For this you would want to create a trigger, (if you are using a sql database)see trigger in mysql, so that every update on the table will trigger a function that stores what was changed and who changed it in another table
So yes, to answer your question, it is totally ok to have a model to store a value, and don't worry about only have one row, you will have more as you develop your app.
The config/globals.js file seems to be a good place to place a global configuration setting.
For convenience, Sails exposes a handful of global variables. By
default, your app's models, services, and the global sails object are
all available on the global scope; meaning you can refer to them by
name anywhere in your backend code (as long as Sails has been loaded).
Nothing in Sails core relies on these global variables - each and
every global exposed in Sails may be disabled in sails.config.globals
(conventionally configured in config/globals.js.)
Sailsjs.org Documentation - Globals
Alternatively you can use the sails.config object.
Custom Configuration
Sails recognizes many different settings, namespaced under different top level keys (e.g. sails.config.sockets and
sails.config.blueprints). However you can also use sails.config for
your own custom configuration (e.g.
sails.config.someProprietaryAPI.secret).
From the docs
There is also services which is global by default.
Overview
Services can be thought of as libraries which contain functions that you might want to use in many places of your application. For example,
you might have an EmailService which wraps some default email message
boilerplate code that you would want to use in many parts of your
application. The main benefit of using services in Sails is that they
are globalized--you don't have to use require() to access them.
It really depends on what kind of global you are wanting.
I have two "cq:include" in same jsp with same path and I need to make both of them editable. But currently only one of them is editable.
If I change anything in one component that shows on second. But the second one itself is not editable. My requirement is to make both the components editable while keeping the include path same.
Code:
<cq:include path ="abc" resourceType="xyz"/>
<cq:include path ="abc" resourceType="xyz"/> # This one is not editable.
Having two components with the same resource type would create only a single node at the given path. Hence, any change you make in one of the component would be reflecting in both of them, as both the components would be reading from the same node.
This is also the reason for not being able to edit the second component. Try providing different paths for different components like shown below.
<cq:include path="abc" resourceType="xyz" />
<cq:include path="abc_0" resourceType="xyz" />
Similar questions have been asked here and here
The way the authoring system works it hooks per location so if you want to have it authored in two different places those two different places should NOT be on the same page. This is just good usability as it can be very confusing.
INSTEAD, I suggest the first one on the page add an attribute to the slingRequest noting that it has been placed on the page and future instances with the same path put a message on the screen saying that it is edited elsewhere. Without knowing more details it's hard to suggest the best usability for this scenario.
Update:
If you MUST do this, here is a work around.
Step 1: define a convention for naming 2 properties. e.g. realTitle (String) and realTitleLastUpdated (date/time). These will be page-level properties, making it easy to access and check them using pageProperties. Though you can do this through a subnode as well but that gets more complicated.
Step 2: For the components that must all be simulateously editable, allow them to create their own nodes. Then, on load in the EDIT environment, check the property realTitle and the lastUpdated time stored in realTitleLastUpdated
If the last edit of your component's title, e.g. jcr:lastModified is newer than realTitleLastUpdated, change the local value of title (e.g. jcr:title) to the value of the realTitle property and update the realTitleLastUpdated time to reflect the time in jcr:lastModified on your component.
If the opposite is true - realTitleLastUpdated is of a time newer than the last modification of the local component, then update the jcr:title of the component and the times to match.
Obviously if the last update times match, do nothing.
It's a bit of a run around, but this will keep everything in sync.
I realized that you may not realize that you probably need to save the state. I believe you can do this (among other ways) using resource.getResourceResolver().adaptTo(Session.class).save()
I've done this before but it's been a while. Let me know if you have issues, I'm working from memory.
Well, if you don't want author to bother about editing both the components, then you should use javascript/jquery and onChange() of one of the component, modify the value of another component as well.
I have two different contexts on a Plone instance.
The first context has some ATFolders. The second, have ATFolders too that have to be in sync with the first context using some subscribers.
In the second context, the ATFolders have to know that they are linked to some of the folders on the first context.
I thought about using setattr in them (setattr(obj_context1, attr, obj_context2.UID())) instead of creating a new Content-Type just to have a ReferenceField attribute (or using archetype.schemaextender), since this would be too much overkill for just a single parameter in a specific context: the folders that will have this attribute will not be deleted from ZODB for example. They will have a placeful workflow with just one state. This attribute is completely hidden from the user, and the folders on the second context are programatically created, with no user intervention.
This attribute should only exist in the second context, so creating an adapter or a new content-type, just to be used in this context seems to be too much.
I'm inclined to use setattr for the sake of pragmatism on this specific scenario, but I don't know if using the setattr approach is going to haunt me in the future (performance, zodb conflicts, etc). I mean: doing an update catalog, update workflow, is this new attribute going to have a problem?
Any thoughts? Anyone experienced with setattr in this situation? This attr will and should not be visible, it's only for some control.
I don't think it's bad practice at all, I do similar things for similar situations.
You could use an attribute annotation, which would help prevent conflicts with other attributes, but that's a style and performance choice more than anything. Attribute annotations are stored in their own ZODB persistent record, so it depends on how often this attribute will change compared to the other attributes on the folder what impact this has.
Last but not least, I would probably encapsulate the behaviour in an adapter, to make the implementation flexible for future uses. You can either register the adapter to the ATFolder interface, or to IAttributeAnnotatable, depending on how much your implementation relies on what the adapted object needs to provide.
Other notes: We've also used plone.app.relations connections between objects in the past (maintained outside the object schema, like your attribute), but found five.intid (the underlying machinery .relations relies on) to be too fragile and would use simple UID attributes with catalog searches in the future.
In reference to Ross's answer, if the information in question doesn't need to be end-user editable, a schemaextender attribute is overkill.
Maybe use archetypes.schemaextender? See also this doc. This way you can use an actual ReferenceField, get all sorts of stuff for free, and spend a lot less time re-implementing said free stuff.
I'm building a site with OpenAtrium Drupal installation profile. I want to have multiple content types of "cases" that can be tracked together (obviously they would all share the basic case fields). I'm wondering what the best way to approach this is. Should I make an override module that overrides atrium_casetracker? Should I make a completely new feature?
I've been in this position before. Here's what I recommend.
Create your new feature. Possibly even one new feature per case type if each case has a lot of associated configuration and customization code.
Modify the casetracker_case_node_types variable so your content type is recognized by casetracker as being a case type. You need to do this before creating nodes of your new case type, otherwise you will have migration complexity. (See http://drupal.org/node/734542 to make that better.) **For compatibility with OpenAtrium's Atrium Casetracker feature, modify this variable with hook_strongarm_alter() to avoid creating a feature that conflicts with Atrium Casetracker.
Be sure when exporting your content type that all variables and node options are properly configured and exported with your content type, such as the atrium updates variable and the og usage variable.
If you need to change the default case, you can export CCK fields and other configuration related to that node type in your new feature.
If you have questions on this, please comment and I will update my answer to clarify further.