Idea Details

FOKUS: More flexible wildcard and redundancy mechanism in LOGIN objects

Last activity 05-31-2019 02:24 AM
Carsten Schmitz's profile image
04-13-2018 04:37 PM

In UC4, agents determine the desired user account by looking for matching accounts in a LOGIN object.

LOGIN objects have extremely limited wildcard functionality: one can use exactly one wildcard, namely the asterisk, which can not be part of an expression but only stand on it's own. In other words, LOGIN objects can only have one wildcard entry: *

The cascade in UC4 then works like this:

1. is there a specific entry for the agent? If so, use it.
2. is there a wildcard entry? If so, try to use that.

I propose two adjustments to this, to make LOGIN objects much more flexible:

a) for the agent names, allow expressions with wildcards as a part of the expression. So one can have for example these LOGIN Object entries:

  a1) *
  a2) UK*
  a3) UKHQ

This should be resolved by the most specific entry first. In this case, an agent named "UKHQ" would use the third entry, an agent named "UKOFFICE" would use the second entry, and an agent named "USOFFICE" and thus not matching the second OR third entry would use the overarching wildcard from the first entry.

b) ADDITIONALLY, I propose the introduction of a new column in LOGIN objects to designate a hierarchical order (from here on called "level"), very much like the ordering of permissions in the permission system. Thus one could have a LOGIN object with entries such as:

  b1) *   level 0, accountname "flamingo"
  b2) *   level 1, accountname "pelican"

In practice, UC4 shall process the levels by their given order, ascending. So for an agent matching the wildcard, it shall first try the account "flamingo" and if the login fails, it shall try the account "pelican".

The former should be straightforward to implement, as any greedy-type regex engine should be able to resolve the most precise expression for a given agent name. It could, in my assessment, be implemented without breaking backward compatibility.
The later would require signficantly more implementation effort (as it requires changes not just to LOGIN objects, but also to the way jobs are started). It can be implemented fully backwards compatible in my assessment simply by making "level 0" the default for all existing LOGIN object entries.

If supporting this proposal, please indicate in the comments how important part "a" and part "b" is to you, respectively.



12-06-2018 05:09 AM

I think there's a duplicate here:

Partially qualified server names in Login objects 

05-18-2018 12:49 AM



I can not edit ideas. Please prefix this with the "#FOKUS" tag for me, and please assign to the "Automation Engine" category. Thanks!

05-18-2018 12:49 AM


forgot to add, can't edit idea ...

05-18-2018 12:49 AM

I added the #FOKUS tag on your behalf