I'm new in symfony2 and I'm currently facing a problem. I would like to restrict the access on some of my page based on some dates contained in my database.
For example all the page after my mon.site/home/ would be redirect on an error page. I have already thinking on a event listener, but don't know how to restrict on some URL. Is there a better way to implement this function? If not how can I do it?
It's quite straightforward to me. You can choose between two different solutions
First solution
1) Create a custom event and event subscriber.
2) Dispatch event you've created at 1) everywhere (in every action) you need an extra control
3) Inside the event subscriber call for a method into custom event or directly a method of the subscriber to check if the "request satisfy your needs"
4) Raise an AccessDeniedException.
Second solution
1) With DependencyInjection create a custom configuration where you can specify what controller's actions should be checked for the condition you wish
2) Create an EventListener that listen for kernelRequest event
3) Into EventListener just check for condition
4) Raise an AccessDeniedException.
For restricting access you can use:
voters (and also using different strategies of access decision
manager)
you can also restrict access for whole sections of your app, using
access_control option in your security.yml
you can also use acl
try to avoid using listeners.
P.S. and also if this not enough you can configure .htaccess
Related
I have a page which allows a user to update a record, lets call it /edit-record, I want to support /edit-record/1 as a route which would load the data (I tried using getInitialProps) but I also want to make it so /edit-record is a page (ideally the same page) but without the API call to fetch the details happening.
So if I pass /edit-record/3 it should fetch record 3, if the url is /edit-record it just awaits user events.
The issue being I tried a conditional in getInitialProps, a if(query.recordId) {} but the else clause returns a null which NextJS doesnt like; it also just feels a bit wrong in terms of the approach.
What is the better way? Ideally I don't want to create two page files to handle the two conditions as all of the logic is the same.
Hi I have a question about symfony application architecture,
In my application I create different user, but when a user is created, updated, deleted, or his picture change, I need to do some action.
What is the best way to do this ? I excluded to do this on a controller action. There is 2 others solutions :
Create differents events like user.created, user.updated, ... And dispatch it on the controller action and make different listener to do the different action like MailListener (for user.created) TaskListener (for user.created) for add a task.
Use a service like UserManager and on this service have a method like userCreated() and on this method call differents actions like sendMailOnCreated, addTaskOnCreated for example.
For you what is the best method ?
For me, your first solution is the best one. It's clearly a use case for the Event component. It will be easier to maintain and more readable.
Moreover, if you need to add more listener you just need to create another one and bind it to your event. You don't need to modify your controller anymore.
I have a node type that should only be edited by users under certain circumstances that go beyond the permissions their role has. I am doing this in a custom module.
I would like to remove the ability to even see the edit tab, and not just add a validation function to the form that will alert the user after the form is submitted.
I need to add some sort of access function. Anyone know how to do this?
Thanks in advance.
--Update--
I now have 2 ways that should work.
1) Using hook_nodeapi:
function mymodule_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
switch($op) {
case 'prepare':
if(!mymodule_access_function($node)) {
$_REQUEST['destination'] = 'my_access_denied_page';
// rest of function
2) I can insert a access callback function into the menu item using hook_menu_alter.
For my purposes, 2 makes more sense. I thought I would spell out the code for (1) though since that was the answer given on this page and it works.
For the tabs visibility you can alter the themed output anywhere from a module hook to a theme template or css patch. Depending on the requirements for data visibility and performance issues some solutions are better than others. We need more details on what kind of processing you need.
For access, hook_nodeapi(), $op is 'prepare', run your custom code against $node at this point, and decide what you want to do (like redirect to another form if a requirement is not present, or to an access denied page).
Edit: Redirecting is usually done with $_REQUEST['destination'] = 'destination/alias' (does not break execution), sometimes drupal_goto('destination/alias') (breaks execution) is suitable but often it doesn't work. Please keep redirects tracked on your project, as with multiple logic conditions you may end up with unwanted and hard to debug behavior.
Every content type has default permission settings in admin/user/permissions for creating,editing ,deleting node . You may assign to anonymous or authenticated users. If you want assign to group then create another role and assign permission as mentioned above.
I have the following scenario:
Editor Role should not be allowed to
delete nodes. Therefore the corresponding
permission is de-selected in the
permissions page.
However Editor
should be able to to delete nodes
from Views Bulk operations. Using
Rules an action is created called
"safe delete" that checks things like
if the node is not published etc.
before deleting the node.
The problem is the Views Bulk Operations respects Node permissions. Editor will not be able to delete the node as he has not been given that permission. Is there a way that Editor can become a higher role user (as sort of sudo) while performing that action in VBO? Alternatively is there a way to tell VBO to ignore node access for this action?
I'm sure this is a mainstream requirement but I can't seem to find a solution.
Solutions which do not involve programming will be preferred.
The simple, but not-so-clean way, is the route you already took, but with an additional, small module to help it.
has a function my_module_can_delete($user), that returns TRUE if the user is allowed to delete, FALSE if the user is not.
implements hook_form_alter() to modify and delete the button on the node_edit form, if my_module_can_delete($user)
implements hook_form_alter() to modify the confirm form that is called on /node/%nid/delete, and add a message there, telling the user he or she my_module_can_delete($user). This should be enough, since disabling this form will result in users not being able to get past this form. FORM-API will take care of that.
However, you can make it more sturdy, to catch other deleting modules:
implements hook_nodeapi(), $op == 'delete' to catch delete actions and halt (by invoking drupal_goto(), or calling drupal_access_denied() to enforce a user-error. Only catch delete-actions if the referer was the delete-confirm-form as mentioned above. Or, more secure, whitelist your VBO-action and return false on all other referers. A referer can often be found by reading out the $node passed along to hook_nodeapi().
A, IMHO, much cleaner, but probably more intensive alternative, would be to simply make sure your batches/actions are called on every delete action.
In a module, you could do this by avoiding all the VBO-configuration and leaving all the extra-delete actions out of there.
Then write a module that implements hook_nodeapi() and then calls all the cleaning actions from there. That way you can be sure that your delete-actions are called on every delete-action on any node. Obviously you can add some conditions into your hook_nodeapi() to only invoke your modules in certain cases (node-types, user-roles, permissions and so on).
Well, it seems to me that you've got a setup where you don't want Editor Role users to delete things, really, except in certain extreme situations. Here's my suggestion:
1) Install Flag module. Create a 'To Be Deleted' flag that can only be assigned by Editor Role people.
2) I haven't looked into it, but I"m sure there's probably a rule or trigger/action combo which will unpublish the node when the 'To Be Deleted' flag is assigned to it. This will remove the node from casual view.
3) Then either set up some cron run activity (trigger/action or rule) to delete nodes with 'To Be Deleted' flag set on them, or have another user with higher permissions come in occasionally and delete out the flagged items.
This way you're not actually bypassing the permissions system, and yet things are still being removed from your site.
I got caught out of this for a while until I noticed the "actions_permissions" module, enable this and on the Permissions page you can provide access to specific actions on a role by role basis.
I don't have a good no-coding solution, and I'm not sure I would call this solution "great" - but one way might be to implement a simple module with a form_alter hook that removes the delete button from the node edit forms as they are built.
In general it seems like the role either has permission to delete nodes or not, and monkeying around like this is going to be less robust that you might like.
I'm building a Drupal based site that requires the communication of a node ID to a seperate web service. This web service handles the uploading of files to a seperate server (from the one Drupal is on).
This creates a problem where in if I create a new node, the Node ID is not generated until the form is submitted - meaning I can't attach the files until I save the node and open it back up to edit it. I'd like to remove that step.
Is it possible to create a two step node creation process where the basics of the node are submitted and saved, and then the form re-directs to step two where I can attach the files?
I'd also consider an AJAX enabled node submission form - but that seems to add even more complexity to the situation.
Any advice, examples will be appreciated!
you could do this with a multi-step form. see http://pingv.com/blog/ben-jeavons/2009/multi-step-forms-drupal-6-using-variable-functions for the canonical way to do this (besides the code, also check the comments).
you could also do it by adding a second submit handler to the form. the first, default one (node_form_submit) saves your node (including the attached file) the standard Drupal way. the second handler could upload the file to the separate server, do upload error checking, delete the file from the Drupal DB, etc. you can add an additional submit handler to a Drupal 6 form by adding it to the form's #submit property, either in the form definition or via hook_form_alter / hook_form_FORM_ID_alter.
Depending on what exactly you want to do, you might use hook_nodeapi on its 'insert' operation. It is fired after successful node creation, so the node object will contain the newly assigned nid there already.
NOTE: The wording of the API documentation is a bit ambiguous concerning the 'insert' and 'update' operations:
"insert": The node is being created
(inserted in the database).
This sounds like it is right in the middle of the process, whereas the node has already been created at this point.
I guess the node_save function can help you.
I ran into exactly this same issue and did it the wrong way. I added the hook myself.
http://drupal.org/node/313389