I'm trying to count failed and successful logins for my users. For that, I simply want to increase the respective counter in the datebase whenever an authentication attempt succeeds or fails. But I want to keep the default behavior without reinventing it.
So I followed this post: Symfony2 hold behavior when extending DefaultAuthenticationSuccessHandler
But apparently I cannot add any parameters to the constructor of my subclass of DefaultAuthenticationSuccessHandler or Symfony complains that the argument types are wrong.
How can I inject my user management service as a constructor parameter??
EDIT: Actually, the problem seems to be a little bit different! I have the following line in my services.yml:
services:
security.authentication.success_handler:
class: %security.authentication.success_handler.class%
arguments: [#my_stuff.my_user_management_service, #security.http_utils, {}]
But the second argument passed to the constructor is an array containing the options like "login_path". But it's supposed to be an instance of HttpUtils. I'm confused...
I figured it out by myself: the order of the parameters is important. I had to move my_stuff.my_user_management_service to the end of the parameter array like so:
arguments: [#security.http_utils, {}, #my_stuff.my_user_management_service]
I don't really understand why, though. There is something wrong with the parameter injection. Maybe someone has some insight??
Related
This is about an API handling the validation during saving an object. Which means that the front-end client sends a request to the API to a specific end point, then on the back-end the API creates a new object if the right conditions are meet.
Right now the regular method that we use is that the models has a ruleset for each fields and then the validation is invoked when the save function is invoked, but technically the validation is done right before the object is saved into the database.
Then during today's code review I came across a solution which I wasn't sure if it's a good practice or not. And it was about that the front-end must send a specific parameter to the API every time. This is because other APIs are using our API as well, and we needed to know if the request was sent as and API request or a browser request. If this parameter is present then we want to execute an extra validation function on a specific field.
(1)If I would have to implement it, then I would check the incoming parameter in the service handler or in the controller level, and if I got one, I would invoke the validation right away, and if it fails I would throw an error.
(2)The implementation I saw however adds an extra variable to the model, and sets the model variable when there is an incoming parameter, then validates only when the save function is invoked on the object(which first validates the ruleset defined on the object fields, then saves the object into the database)
So my problem with (2) is that the object now grown bigger with an extra variable that is only related to a specific event. So I would say it's better to implement (1). But (2) also has an advantage, and that is when you create the object on different end point by parsing the parameters, then the validation will work there as well, even if the developer forget to update the code there.
Now this may seems like a silly question because, why would I care about just 1 extra variable, but this is like a bedrock of something good or bad. So if I say this is ok, then from now on the models will start growing with extra variables that are only related to specific events, which I think should be handled on the controller/service handler level. On the other hand the code would be more reliable if it's not the developer who should remember all the 6712537 functionalities and keep them in mind when makes some changes somewhere. Let's say all the devs will get heart attack tomorrow from the excitement of an amazing discovery, and a new developer has to work on the project while he doesn't know about these small details, and then he has to change something on the code that is related to this functionality - so that new feature should be supported by this old one as well.
So my question is if is there any good practice on this, and what do you think what would be the best approach?
So I spent some time on thinking on the solution, and I think the best is to have an array of acceptable trigger variables in the model class. Then when the parameters are passed to the model on the controller level, then the loader function can be modified that it takes the trigger variables from the parameters and save it in the model's associative array variable that stores the trigger variables.
By default this array is empty, and it doesn't matter how much new variables are needed to be created, it will only contain the necessary ones when those are used.
Then of course the loader function needs to be modified in a way that it can filter out the non trigger variables as well as it is done for the regular fields, and there can be even a rule set of validation on the trigger variables if necessary.
So this solves the problem with overgrowing the object with unnecessary variables and the centralized validation part, because now the validation can be always done in the model instead of the controller.
And since the loader function is modified to store the trigger variables in the model's trigger variables array variable, the developer never has to remember that this functionality was created. Which is good, because in the future when he creates a new related function or end point that should handle object creation, he will not miss it to validate it against the old functionality, because the the loader function that he modified in the past like this will handle it for him.
It needs to be noted tho, that since the loader function doesn't differentiate between the parameters, and where to load them other then checking the names of the parameters with the filter functions, these parameter names should be identical from each other, otherwise a buggy functionality can be created accidentally. Like if you forget that a model attribute with the same name was used, then you can accidentally trigger an event that was programmed to be triggered if the trigger variable with the same name is present. However this can be solved by prefixing the trigger variables for example.
I am trying to instantiate an actor system with non-default behaviour (e.g. clustering or remoting) but no matter what I do the ActorSystem always ends up with default configuration. The config object and settings object appear correct (e.g. actor.provider == cluster) but the actual run-time object always has defaults.
I've tried constructing the config many different ways. With App.config cdata and by manually parsing a config file with ConfigurationFactory and passing it in to Create. I had the problem with 1.4.3 and with 1.3.17.
I downloaded the Akka source code and debugged it. Stepping through the Create method I found that the root HoconObject's items dictionary contains 2 entries with the key "akka". One entry is mine, the other looks like a fallback. The getter method resolves the fallback.
I guess there is some weird string formatting happening...
[Update] There seems to be confusion about what is actually happening. Here is a screen-shot of what HoconObject looks like when it works:
In the screen-shot you can clearly see a single entry in the Items dictionary for "akka" that is set to "provider=cluster", which isn't the default and is coming from the config file. The previous screen-shot shows 2 entries, one of which is "provider=cluster" and the other is clearly the default that Akka injects. Both key = "akka". The bug causes Akka to select the default rather than the override.
I understand that Hocon allows overrides from defaults but that isn't what's happening. Again, if you look at the source code for HoconObject you'll see the screen-shot is of a plain .Net dictionary called 'Items' and the TryGetValue is the .Net implementation... not a Hocon implementation.
This is obviously a parsing bug that cases Akka to behave incorrectly and throw no exceptions.
I don't have enough reputation to post my question as a comment.
Do you have a code I can use to replicate the problem? A code snippet of how you build your config would be fine.
I downloaded the Akka source code and debugged it. Stepping through the Create method I found that the root HoconObject's items dictionary contains 2 entries with the key "akka". One entry is mine, the other looks like a fallback. The getter method resolves the fallback.
Yes, this is the actual behavior of a HoconValue. a HoconValue is a list of value fragments that will be converted into a proper data type when you call the appropriate getter function. For example, the HoconValue instance that you see in your debug session is actually 2 HoconObject fragments, and the proper merged object can be retrieved by calling the GetObject() function of that HoconValue instance.
In Meteor JS I want to perform a task before adding an object to my collection. So I created my own method, eg: addObject like so:
Meteor.methods({
...
addObject: function(obj) {
/*
// this is what i'm trying to figure out...
if ( !MyColl.allow('insert', Meteor.userId, obj) )
throw Meteor.Error(403, 'Sorry');
*/
MyColl.update({ ... }}, { 'multi': true });
MyColl.insert(obj);
},
...
});
But I noticed that .allow is no longer being called because it's "trusted" code. The thing is the method is on the server but being called from the client (through ObjectiveDDP) so I still need a way to validate that the client has permissions to call addObject - is there any way to manually call .allow() on a collection from my server code? I tried it but getting an internal server error, and not sure what the syntax should be... couldn't find anything in the Meteor docs.
Edit:
I just found out that this works:
var allowedToInsert = MyColl._validators.insert.allow[0];
if (!allowedToInsert)
throw new Meteor.Error(403, 'Invalid permissions.');
But that's probably a no-no calling private methods such as _validators. Does anyone know of a more 'best practices' way?
You can do validation in the addobject method. For example, if you only want logged in users to be able to add an object, you can write:
if (!Meteor.user()) throw new Meteor.Error();
at the beginning of the addobject method.
Personally I never use allow.
On a related note, the collection2 and simple-schema packages can often help a lot with validation.
The validation pattern you are using might not be the best way to do things.
If you assume that methods can be called from the client, you shouldn't 'hack' it into doing something it's not meant to do.
If you are calling a method that changes data in the database you should check within that method that the currently logged in user has permission to do so.
However, are you sure you want to do this? Meteor also has Collection.allow and Collection.deny methods that you can use to define read/write/update/delete permission with. That's the recommended way to handle permissions, so what you are doing is an anti-pattern. However, perhaps in your case it is strictly necessary? If not, you might want to rethink the use case.
Like another response suggests, using something like Collections or SimpleSchema to validate data structure is also a good idea.
Is there a way to initialize() ("re-open") an existing JSONStore collection with the same arguments that were used to create it, without passing them again? E.g. without specifying the searchFields that were set up on its creation.
Not possible, you must always pass the same arguments (search fields, etc). You can open a feature request here if you want.
JSONstore does not provide a way to do what you are asking about - init() doesn't keep any "memory" of the arguments that were previously passed to it, so if you want to re-open a collection, the arguments to init() must be passed again.
My scenario is the following:
I have a workflow (lets call it customActivity1) that do the basic actions for my system. I also have another workflow (customActivity2) that uses customActivity1 and do higher level actions. When I call customActivity1, I must pass on a few parameters, like Boolean or String values. I want to show some of these parameters as a checkbox or combobox (so the developer of customActivity2 can pass on only valid values) and found out that I can do that by setting the argument as PROPERTY (instead of In).
By doing a research, I also found out that you can’t directly use this argument in expressions, so I keep getting errors on my customActivity1.
That said and knowing that I need to narrow what the designer can pass on, how could I do that without using an activity designer or where could I find an answer?
I also attached two pictures, one of what I need and the other of the error I’m getting.
Thanks in advance.
The reason an InArgument only shows you a text field instead of a checkbox is because they are expressions not literal values. There is still type checking though, if you enter the value 1 you get the error message that an integer cannot be converted into a boolean.
You cannot do this. You can only bind to InArguments.
If you bind an InArgument and look at the xaml, you'll see something like this:
<p1:MyActivity MyInArgument="[BoundValue]" ...
The Workflow Runtime knows how to handle these. It doesn't know how to handle binding POCO properties.
If you want to model data flow but want to have a different user experience in the property grid I recommed using arguments (as they convey data flow semantics) and customizing the property grid for those arguments. There is a sample that demonstrates how to do this in the WF4 samples (sample readme available at http://msdn.microsoft.com/en-us/library/ee834515.aspx)