[8.160][BUG][FIXED] Question: Blank name fields get REF IDs

I know we can use resolve ref tool under suport->advanced to get some kind of idea about the REF IDs as to where they are being used but I noticed that you can create rules without names in the new application control system. 

Isn't there any way that all the fields are checked and an error pops up if the name field is missing? We should be getting rid of REF IDs and not expanding them[:S]

Regards 
Bill.
  • Astaro Beta Report
    
    --------------------------------
    Version: 8.160
    Type: BUG
    State: MERGED/FIXED
    Reporter: Billybob++
    Contributor: 
    MantisID: 17035
    Target version: 8.161
    Fixed in version: 8.161
    --------------------------------
  • This will be a funny one... stay tuned, cause i'll write a longer explanation later today ;-)
  • Okay, i have to admit that "today" was a little bit too optimistic. But now, at last, here comes the explanation i promises:

    Some of the things that developers improve for a new version will never get mentioned in release announcements, because they are "under the hood", hidden in the internals, where ordinary users normally don't look at. Even if they are mentioned, they usually get buried under a ton of shiny buzzwords like "performance improvements" and so on.

    [SIZE="4"]Let me introduce you to the "human-readable" REF_IDs.[/SIZE]

    As you all know, there are lot's of things in the ASG which you can manage: networks, interfaces, users, packet filter rules, http exceptions. We call them "objects" and they have a similar internal structure. And because they are so similar, you can use eg. a "DNS Host" and a "Network" together in a packet filter rule.
    On the other hand we need to be able to quickly find each single object, and therefor we give each object a unique identifier, the REF_ID. And this is not restricted to the objects that we ship. Every user that you create, every interface, every host or service, everything that you create to configure your ASG also gets such an unique ID.

    You normally don't have to deal with these IDs, and they are invisible to you most of the time. Because they have to be efficient for the computer, we chose a rather concise format. It's just a string of characters and numbers after a leading "REF_". Up to version 8.1xx the part after the "REF_" was purely random.

    As stated above, this is for the computer to efficiently find those objects, and not for you as a human. In addition to the REF_ID that the computer uses, each object has a "Name". In the case of user-objects this is the login name, in case of a network this can be anything that fits your needs, from "My Home Network" to "Finance Department".

    So, to put it in once sentence: The computer mainly uses "REF_IDs" while you as a user mainly work with "names".

    We try minimize the places where you as a user see those REF_IDs, and in the places that Billybob named here in this thread, we think that something different should be displayed. In case of the WAF-object (second picture), it should be the text that is displayed when you try to delete that object, but that is a different story (and tracked as Mantis ID 17035).

    If you take a closer look at those pictures above, you'll notice that they aren't completely gibberish, they actually carry a little bit of the objects information in their REF_IDs. That's what we mean by "human-readable". What happens is basically that we put the object class/type and name together and use that as the REF_ID. In case of a user "John Doe" this means that the user-objects REF_ID is "REF_AaaUseJohnDoe", and gives a nice hint what it is.

    We think that this is an improvement in more than 98% of all cases, and in the other cases it isn't worse than the completely unrelated, random characters that were used.

    This only applies to objects that you newly create with an ASG Version 8.2xx, your "old" objects, from the 8.1xx-config that you might have imported, will stay with their old REF_IDs.

    I'm pretty sure that Ingo, who wrote the code for this 'hidden feature', will also write something on this topic if you have questions (or if i messed up with my explanation [;)]), so please feel free to ask.

    Cheers,
    Kai
  • Hi,

    what Kai said is correct.

    However, automatic names are at least as interesting for ASG users as human-readable REF string (technically, both are closely related, and share part of their implementation).

    What are automatic names?

    In 8.10x, when you do not assign a name to an object, you will either see the name "unnamed" or REF strings at most places where the object is referenced.

    In 8.160 and 8.161 (first and second beta), at least in error messages, the name "unnamed" is avoided, and some useful information about the object is shown instead, when available.  However, object tables may still show REF strings, as reported by Billybob.

    Now, for 8.162 (third beta), i have revisited these issues.  Basically, object names then work as follows:
    * When the user manually assigns a name, that name ist used.  Period.
    * When the user doesn't assign a name, an automatic, human-readable name is assigned, based on the properties of the object.  In case you don't like it, edit or replace it, save it, and then it will stay for good.
    * As long as you don't manually assign a name, the name will always be updated when the properties of the object change.

    For example, in 8.162, go to Definitions >> Networks, click "New Network",
    enter an IP address, do not enter a name, click save.  The IP address will be used as the name as well.  Click edit, change the IP.  The name changes as well as soon as you save the changed object.  Click edit, assign your own name, and it will not change any longer.  Click edit, delete the name *completely* (do not leave a single letter), and you are back to automatic names.

    Enjoy.

    Ingo