[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.
Parents
  • 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
Reply
  • 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
Children
No Data