• (nodebb)

    She loves it when I get access to section G.

    Ok I'll see myself out

  • (nodebb)

    Yeah, if that fall-through pattern is a correct implementation of a business rule, it should fscking well be commented as such.

    But what really grinds my gears is that that long test is repeated ad nauseam instead of being centralized.

  • Jim Jam (unregistered)

    Notice the beautiful inconsistency: to provide access to SectionA there must be an entry other than NoAccess, while for all the others missing value gives the access to the corresponding section.

  • (nodebb) in reply to Jim Jam

    And also the mysterious use of else return UiItem.Unknown; when that is not in the enum definition for UiItem which should be an error.

  • Industrial Automation Engineer (unregistered)

    TRWTF, however, is that the random-generator used on this site to go to a "random" article, has the same quality as the submissions posted here.

  • (nodebb) in reply to Jim Jam

    Notice the beautiful inconsistency: to provide access to SectionA there must be an entry other than NoAccess, while for all the others missing value gives the access to the corresponding section.

    Yeah, someone failed hard at De Morgan's Law on this one.

  • (nodebb)

    So if currentAccess is empty we always get UiItem.sectionB?

  • (nodebb) in reply to Steve_The_Cynic

    Yeah, someone failed hard at De Morgan's Law on this one.

    10 years in chroot jail for this violation.

  • (nodebb)

    Wow! Messy.

    It seems section A is special and sections B-G is not as special.

    For section A/highest level, you need to have access (an entry in the currentAccess-map/table/array, whatever it is) and it cannot be NoAccess.

    For sections B to G you have automatic access unless you have been denied access (NoAccess again).

    Which of course will cause all kinds of funky security incidents, but maybe it makes sense for this app. E.g. section A is admin access, B-G is different parts of the public site?

    Anyway, messy!

  • Loren Pechtel (unregistered)

    Why am I seeing this differently? To me it looks like we have a set of key-value pairs that define access and this is trying to pick the first item that the user has access to, perhaps to set up a default on the screen as this is UI code. Effectively an unrolled loop but where's the errant behavior?

    But there's another problem: reCAPTCHA thinks a motorcycle is a bicycle!

  • (nodebb)

    Oh boy this looks so similar to our Fortran code...

    select case(obj%type)
case(objtype1)
    call subroutine1(obj%obj1field)
case(objtype2)
    call subroutine2(obj%obj2field)
...
end select

    It is basically object orientation done backwards. But the one code had been started in the 90s, and back then Fortran didn't have polymorphic types, so it gets a pass to some degree. Also, I was just learning the alphabet when the first version of the software was written, so I'll give them a pass for getting ad-hoc object orientation wrong.

    Regardless, it can be quite a pain to work with. Conditionals and switch-case (i.e. select case in Fortran) everywhere.

  • Craig (unregistered) in reply to R3D3

    F90 does have generic interfaces giving polymorphism akin to C++ templates with everything explicitly specialized, but it doesn't look like that would help with that style of object discrimination.

  • (nodebb) in reply to Craig

    As far as I know, Fortran has only overloading of names, in that it allows defining multiple subroutines/functions/method that are are called through the same name. By trying out right now I learnt, that they can after all also be defined in different modules.

    But that's not the same as templates or Java generics, because it requires manually implementing them for each type. It can be somewhat automated with macros, but that's still hardly a replacement for proper language support; For a start, being based on a custom workaround also means that it won't have TOOLING support.

    A natively supported alternative is to use CLASS(*), ALLOCATABLE for storing the data. But for some reason, a simple

    type :: node_t
    class(*), allocatable :: payload
end type node_t

    has 128 byte in Intel Fortran (24 in GFortran), so that's not actually all that attractive. There's also the problem, that there is no concise way to get the data out of that again, unless you define something like

    function tochar(obj)
    class(*), intent(in) :: obj
    character(:), allocatable :: tochar
    select type(obj)
    type is (character(*))
        allocate(tochar, source=obj)
    class default
        error stop "type error"
    end select
end function tochar

    but that shifts the type check to the runtime.

    Best I could come up with was to store the payload data via the TRANSFER intrinsic, but who knows what kind of breakage that introduces with regard to finalizer behavior, such as automatically deallocating allocatable fields of items that go out of scope.

Leave a comment on “A Secure Item”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article