First, I don't think that this service has any secret information that should be kept under authorization/authentication.
Even if we assume that some level of auth is indeed needed, the easiest way to implement it would be through Rack middleware. If the service is added to an application with existing auth middleware, then you can add it to the relevant endpoints when mounting it. In case we are trying to use the standalone version, we can either create an extension point to add middleware, or mount it manually, just like in the previous case. Anyway I don't see a reason to limit access to those endpoints, except only for cases of DDOS (which should be handled even before the Rack stack anyway). On Thu, Sep 14, 2017 at 10:44 AM, Ivan Necas <[email protected]> wrote: > How would be the authentication/authorization work with this approach? > > - - Ivan > > On Wed, Sep 13, 2017 at 9:05 PM, <[email protected]> wrote: > > > > First attempt to create a design. It's an open discussion, everyone who > > wants to chime in, please do. > > > > The engine: will be deployed as a separate gem. My name suggestion > > the-detective (Sinatra plays a cop). > > > > It will wrap the invocation of rubocop with defaults and parameters > needed > > to support our use case: > > 1. Support for erb > > 2. Support for completely customized set of cops. > > 3. Parametrized list of folders containing cops to be added to the list. > > > > In addition it will add tooling to expose a rack endpoint for rubocop > > invocation: > > 1. List of all available cops (kind of metadata) > > 2. A POST method that receives a source file, list of cops, and output > > format that will return the result of rubocop's analysis. > > 3. Will be mountable to any Rails application > > 4. Will have an option to run as a standalone process (probably using > > passenger with sort-lived process retention settings, since its one > process > > per request nature) > > > > Usage for foreman needs: > > > > Use case 1 (community templates CI): > > 1. Reference the detective gem from templates plugin. > > 2. Deploy foreman-core with templates plugin enabled. > > 3. Add rake task that will invoke rubocop on specified folder using > > detective's invocation wrapper. > > > > Use case 2 (Validate single template from templates UI) > > 1. Reference detective gem from templates plugin. > > 2. Add cops declaration ability to plugins in foreman core > > 3. Templates plugin is responsible for adding/maintaining detective's > > endpoint. > > 4. Foreman core exposes an option to add actions to template editing > screen. > > 5. Templates plugin uses extension point from 4 to add its own action > that > > will invoke detective's endpoint and modify template editor to show the > > result as linting (it's possible with ace and monaco). > > > > Use case 3 (upgrade scenario): > > As a first step, we can try and report broken templates after the > upgrade. > > It will be pretty similar to community templates CI use case, only the > > templates code will be exported from user's database. > > > > > > I want to start working on the engine gem as soon as possible, so I would > > really appreciate any inputs on the process before I have started with > this > > implementation. > > > > Shim. > > > > > > > > On Wednesday, August 30, 2017 at 11:48:09 AM UTC+3, [email protected] > wrote: > >> > >> > >> After a great talk on community demo, here is a follow up with the > points > >> that were raised during the discussion: > >> > >> Use cases: > >> > >> Run all cops as part of community templates CI against the whole > >> repository > >> Run all cops against a single template invoked by the user from template > >> editing screen (foreman core) > >> Upgrade scenario: Preferably run cops for the next foreman version > before > >> the actual upgrade to make sure the templates will remain valid. > >> > >> > >> Features: > >> > >> List of rues should be pluggable [Shim]: It looks like it is a must-have > >> for the engine. > >> Deployment options > >> > >> Engine as a separate gem, cops in a relevant repository - core cops in > >> core, plugin cops in plugins. > >> Engine with all cops in a single gem, versioned per foreman version. > >> Engine as part of templates plugin, cops as part of relevant plugins. > >> Separate gems for everything: foreman-cops-engine, foreman-cops-core, > >> foreman-cops-plugin1, foreman-cops-plugin2 e.t.c. Engine is versioned > per > >> foreman release version (for the sake of rubocop version), cops are > >> versioned per plugin version. > >> > >> General comments: > >> > >> Cops writing should be enforced on PR's that are changing the way to > write > >> templates [mhulan] > >> Cops are dependent on core/plugin version [gwmngilfen] > >> > >> > >> > >> > >> On Monday, August 14, 2017 at 2:29:02 PM UTC+3, [email protected] > wrote: > >>> > >>> TL;DR: I have developed a way to scan any template and see if there are > >>> suspicious/incorrect code patterns in them, so the templates will > remain > >>> valid even after foreman code changes. > >>> > >>> Recently I have started to think about user created templates and > foreman > >>> upgrades. > >>> > >>> When user upgrades foreman, hist default templates get upgraded by the > >>> installer/migrations, but templates created by the user (both cloned > and > >>> from scratch) are not touched. > >>> This could lead to invalid templates and broken provisioning > >>> functionality for the user. > >>> Good example for this would be the change from calling to <%= > foreman_url > >>> %> to <%= foreman_url('built') %> > >>> > >>> I was looking for a way to inspect any template, in order to identify > >>> problematic code as soon as the system is upgraded. > >>> > >>> I came down to a solution based on rubocop - it's already analyzing > >>> source files for patterns. > >>> I have created a POC that analyzes a template written to a file, and > >>> presents the resulting errors as regular rubocop (clang style). > >>> All source codes are available as gist: > >>> https://gist.github.com/ShimShtein/341b746f15826261053e97c2f435ff1a > >>> > >>> Small explanation for the gist: > >>> > >>> Entry point: inspect_template.rb > >>> Usage: > >>> Put everything from the gist to a single folder and execute: > >>>> > >>>> inspect_template /path/to/template_source.erb > >>> > >>> This script aggregates all the parts that are needed to create the > >>> clang-like output. > >>> > >>> The process: > >>> > >>> Strip all non-ruby text from the template. This is done by > erb_strip.rb. > >>> It turns everything that is not a ruby code into spaces, so the ruby > code > >>> remains in the same places as it was in the original file. > >>> Run rubocop with custom rules and erb monkey patch and produce a json > >>> report > >>> > >>> foreman_callback_cop.rb custom rule file. The most interesting line is > >>> "def_node_matcher :foreman_url_call?, '(send nil :foreman_url)'". Here > you > >>> define which pattern to look for in the AST, in our case we are > looking for > >>> calls (send) for foreman_url method without parameters. > >>> foreman_erb_monkey_patch.rb file: Patches rubocop engine to treat *.erb > >>> files as source files and not skip them. > >>> > >>> Process the resulting json to convert it to clang style highlighting. > >>> > >>> Possible usages: > >>> > >>> Scanning all template after foreman upgrade to see that they are still > >>> valid. > >>> Linting a template while while editing. > >>> Using rubocop's autocorrect feature to automatically fix offences found > >>> by this process. > >>> > >>> Long shot: we can create custom rules to inspect code for our plugins > >>> too, especially if we start creating custom rules in rubocop. > >>> > >>> I am interested in comments, opinions and usages to see how to proceed > >>> from here. > >>> > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "foreman-dev" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/foreman-dev/KtVSqPKzXjA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
