I have a big role i am looking to pack in a collection, and i want to create a plugin that does calls the role, instead of doing "include_role". so, i am looking for my customers to be able to put something like:
- name: call my plugin
my_plugin:
param1: "mmm"
param2: 42
and that will, internally, run some verifications, but eventually it will call on the entire role to execute (contrary to just calling a module).
all the documentation i found seem to call modules from the plugin, but nothing seems to be able to call a role (or a playbook). is there a way to achieve that?
If you really want to go this way, you can look into include_role source code. (f.e. here https://github.com/ansible/ansible/blob/2cbfd1e350cbe1ca195d33306b5a9628667ddda8/lib/ansible/playbook/role_include.py). It doesn't look to me like a normal pugin, though.
But there is a more serious issue here: If you create something like that, it would totally obscure the role content from the user. Roles aren't 'python modules', and isolation is very weak for roles. By hiding role content (and execution) from users, you create, basically, your own version of ansible, with fresh and unknown list of bugs and quirks.
If you want to control the way code is executed, the strategy plugin may be a more reasonable place. You still allow users to see the usual execution workflow, but you'll have a great deal of control on how things are executed.
But writing strategy plugins is crazy hard. I know only one third party strategy plugin (mitogen).
Related
I've been using a pretty cool package by Max Savin to monitor what is going on in the database and I noticed it has a "duplicate" function. This allows me to enter things into the database even though I haven't defined a method to allow for this. Ie I've removed the insecure package and have methods to allow entering info into the database.
Is this expected behaviour?
From the FAQ on the github page it seems yes? But I'm not sure.
Does Mongol require insecure to work? No, Mongol has special set of
method's that allow it to interact with the database without
disrupting your application permissions.
Is there a security risk to using Mongol? Since Mongol is a debugOnly
package, Meteor's build process will not compile it into production
code.
Yes, this is the expected behavior, this package has its own server-side methods, and it even bypasses common validation libraries: https://github.com/msavin/Mongol/blob/94ede16c02c3764448918c94b4d443528d227e9f/server/methods.js#L59
I have my shell application working and I now want to ensure that a user is logged in before anything else occurs. I have a working auth controller and associated database tables, etc.
I assumed that the best ay to do this was to put the identity test in the bootstrap, as I don't want to check for identity in each controller. Basically, I think I want to put code in the bootstrap that says if identity, then run the index otherwise, run auth. Is this the best way to do it in Zend? If not, what is the preferred method?
I was thinking Bootstrap because for every request of any type, I don't want to allow it if the user is logged in and of course, it would be best to chave this check only in ne place.
I have more commonly seen this in done via a plugin. These can be done at various stages of the Zend Application dispatch cycle. The most common set up I have encountered would be to put a check user login status plugin in at preDispatch.
Search the Zend documentation for preDispatch plugins, or have a look on Youtube as there are some good video tutorials that walk you through it.
An advantage to doing this is that in the future you may want to run some kind of functionality prior to the user authentication test. In such an instance you could put new functionality in a dispatchLoopStartup plugin.
Having said this, there is nothing really wrong with checking the user login status in the bootstrap - I have seen this done many times. It is possibly just tidier to user plugins as they are more repeatable in new applications.
This is just my opinion of course, but I hope this helps.
Does anyone know if there is something similar to log4 available for cache?
I've used log4net on a number of .Net projects and would like to have something with the same capabilities. In particular the logging level and the configuration ability between local,dev,qa,and prod environments.
It's hard to answer definitively that something doesn't exist, but I'm pretty sure it doesn't exist. The only sources I've been able to find for Cache libraries is either Intersystems, of course, or the M/Gateway website (I am not affiliated with the M/Gateway product or website, nor am I endorsing it, it's just the only Cache code repository I've been able to find. It requires registration and has under 50 files, many of them tutorials).
Searching GitHub for "Intersystems" does find some stuff, but "Intersystems logging", though there are some results in the search, none appear to be anything like log4net.
The base Intersystems libraries include things like ^%ETN, which traps and logs error data, but it just puts some specific stuff in globals, it's nothing like log4net.
So, in summary, I wouldn't hold my breath.
You might consider using log4net a basis for rolling your own simplified version. A Cache way to implement it might be to inherit from a logging class to get the Log method. You could get class specific data either by run-time reflection or by having the Log base class include a generator method to fetch the class specific data (more efficient). In Cache a configuration file probably isn't that useful, so I would suggest persistent configuration classes. I would have design it to allow multiple configurations to be saved to disk at once, and some method of designating one as active.
I've just inherited a CF app from a customer who uses a shared CF hosting provider. I'd like to introduce better processes including the ability to stage app changes that I make for their review. (In the past, they would upload changes and cross their fingers.)
Their app lives in a folder under the webroot. Let's call it "/app". I'd like to create a sibling directory named "/appstaging" where I would publish the latest code. The obstacle is that the hosting provider lets you set paths for custom tags and mappings but not per CF app. The existing settings all point into the /app directory so if I need to make changes to tags, CFCs, etc., I can't test these without affecting the live app. What I want is CF to let me set per-app tag paths and mappings. From what I've read, CF8 lets me do this but the customer is using CF7 (I'm pushing for them to upgrade asap). In the meantime, is there anyway to workaround this or does a smooth way of staging changes have to wait?
(I am currently experimenting with ways to detect which app I am based on using GetCurrentTemplatePath() in application.cfm. The idea is that any code that refers to other files using mappings would use a different mapping. I haven't done enough work there though to know if this will all work out.)
Any ideas or input are welcome. I should point out that the app and its dev env is not very "modern." There are no frameworks involved and no things like ant used for build/deployment. The customer's budget is extremely limited so I'm not looking to convert the app whole-sale but I do need to find cheap ways to get some process in there to keep things sane.
This is a serious, but wacky, suggestion: use a second hosted account.
Write up a cost-benefit analysis of having live and staging servers, and compare that to the cost of a second hosted account. The second account doesn't need massive data allowances, etc, and ought not cost as much as the live account.
Additionally, calcuate the cost of revising the code base to allow live and staging on the one account and compare that to the cost of a second hosting account.
Remember that you wont need the second account once your real upgrade is complete.
I expect you'll need to do something like defining the custom tag paths in a config file that gets loaded into the application scope. But that'll require some serious code refitting.
I'm currently using the Jira SOAP interface within a C# (I suppose the language used here isn't terribly important).
Basically, I'm creating an API and a Winform that wraps some of the functionality of the soap service so that our Devs can programmaticly add bugs when something goes wrong in our application.
As part of this, I need to know the custom field IDs that are in use in Jira, rather than hardcoding them (as they are still prone to the occasional change) I used the GetCustomFields() method in the jira-rpc api then filtered it, so that all the developer needs to know is the name of the field, then the ID is filled in for them automagically.
This all works fine, but with one quite important proviso: that you login to the SOAP/RPC service as a user with administrative privaliges.
The Jira documentation indicates that the soap/rpc service follows the usual workflows and security schemes, however I can't find anything anywhere that would appear to remove this restriction on enumerating custom fields (and quite why in any instance you would want someone to HAVE to be an administrator to gain this access, especially as the custom field id's tend to be in Jira's HTML source is beyond me)
Does anyone know if I've missed a setting somewhere? Or if there is some sort of work-around for this, short of hardcoding the custom field id's?
Or is this a case of having to delve in to Jira's RPC plugin and modifying the source for it in order to give me the functionality I require?
Cheers
Edit for the sake of google/posterity
Wow, all this time on, and it looks like Atlassian still haven't changed this behavior.
Worked around this by creating a custom dictionary that logs in as an administrative user, grabs the custom fields and then logs out. Not ideal, but it should work 'til atlassian change things
You're not missing anything - there's no way to get custom fields via standard SOAP API.
In JIRA Client, we learn about custom fields in two ways:
We download issues via RSS view of the issue navigator, or via XML representation of a specific issue. If a custom field is set for an issue, the XML will have its id, class and value (values).
From time to time we inspect the content of IssueNavigator search page - looking for searchers for the custom fields. Screen-scraping the HTML gives us not only ids of the custom fields but also possible values for enum fields.
This is hackery, of course, and it may go wrong, so a good API would have been a lot better.
In your case, I can suggest two solutions:
Create your own SOAP (or REST) remote API plugin that will give you just that info that you miss from the standard API. Since you're seemingly in control of your JIRA, you can install anything there.
Screen-scrape the "New Bug" page for the project and type of issue you need to submit. You'll get all the info - fields, options, default values, which field is required.