Yes, I'm have mainly the DOS (I guess it might not even needed distributed part here) in mind.
-- Ivan On Thu, Sep 14, 2017 at 12:18 PM, Shimon Shtein <[email protected]> wrote: > > 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. -- 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.
