3rd Party Web Service



  • About half the time, you need logininfo. The other half, basicLoginInfo. And this sort of thing is representative of the rest.

       public partial class logininfo {
            private string usernameField;
            private string passwordField;
            private string accountnumberField;
            /// <remarks/>
            [System.Xml.Serialization.XmlElementAttribute("user-name")]
            public string **username** {
                get {
                    return this.usernameField;
                }
                set {
                    this.usernameField = value;
                }
            }
            /// <remarks/>
            public string password {
                get {
                    return this.passwordField;
                }
                set {
                    this.passwordField = value;
                }
            }
            /// <remarks/>
            [System.Xml.Serialization.XmlElementAttribute("account-number")]
            public string accountnumber {
                get {
                    return this.accountnumberField;
                }
                set {
                    this.accountnumberField = value;
                }
            }
        }
    
    
    public partial class basicLoginInfo: basicLogin{
            private string accountNumberField;
            /// <remarks/>
            public string accountNumber {
                get {
                    return this.accountNumberField;
                }
                set {
                    this.accountNumberField = value;
                }
            }
        }
    
    public partial class basicLogin{
        private string userNameField;
        private string passwordField;
        /// <remarks/>
        public string **userName** {
            get {
                return this.userNameField;
            }
            set {
                this.userNameField = value;
            }
        }
        /// <remarks/>
        public string password {
            get {
                return this.passwordField;
            }
            set {
                this.passwordField = value;
            }
        }
    }
    

    Hmmm... is there a way to bold pre? If not, I'll call attention to username versus userName.



  • This appears to be C# code written by someone who just wrote their first non-Java program.

    You/whoever wrote it appears to need:



  • @Magus said:

    This appears to be C# code written by someone who just wrote their first non-Java program.

    You/whoever wrote it appears to need:

    Apologies- I'm cutting and pasting from a 3rd Party Web Service I'm using. I'm not the original author.

    Which isn't to say that I couldn't learn something from that book.



  • I realized that that was probably the case and added the /whoever wrote it, because the chances of someone here actually writing code like that are near zero. But indeed, most C# programmers would benefit from this book.



  • I would hope people who develop in Java would still know about inheritance and make loginInfo inherit from basicLoginInfo. Especially since they already made that inherit from basicLogin.



  • @powerlord said:

    I would hope people who develop in Java would still know

    Any words that follow are a mistake.



  • @powerlord said:

    I would hope people who develop in Java would still know about inheritance and make loginInfo inherit from basicLoginInfo. Especially since they already made that inherit from basicLogin.

    Competent Java developers would do this. Incompetent developers can mess things up in any language.



  • @Magus said:

    @powerlord said:
    I would hope people who develop in Java would still know

    Any words that follow are a mistake.

    Boo! Hiss!

    At least it's not PHP.



  • I get the idea that this is a spare time project for them, developed by several different people over the course of time. The difference in capitalization, in particular- It's logininfo.username, but basicLogin.userName. About half the functions for requesting data are named getNameOfData, the other half are retreiveNameOfData (or retreivenameofdata)

    Hmm- And now that I look more closely, get functions more often use basicLogin, while retreive uses logininfo- but not always.

    Anyway, icing on the cake- The conversation with the vendor went "How can we get a list of all configured users we have in your system?". They replied "Oh, use our web service at https://acb.companyname.com/WebService?wsdl- just use getAllCustomers!"

    Well, that web service didn't have a getAllCustomers, but it did have a retrieveListOfCustomers. It requires a Customer ID. I mention this, asked if retrieveListOfCustomers was what they meant, and what our Customer ID was.

    Day and a half of back and forth later, we find that Customer ID is a random number assigned to each user at creation time. If we want a list of all configured users, we really should use getAllCustomers, conveniently located in https://totallydifferentURL.companyname.com/WebService?wsdl

    Fine. Except now I need to pass it a Company Number. Right now I'm just hoping there's one one, or only a few, and they just assumed I'd know what it was.



  • @cdosrun1 said:

    ```
    public string password {
    get {
    return this.passwordField;
    }
    set {
    this.passwordField = value;
    }
    }

    
    I never understood why my professors required me to write getters and setters and never allowed any public variables. If you're just going to write wrapper functions for basic operators that are part of the language, you may as well be writing a function called `getValueOfArgument` that returns its argument.


  • @cdosrun1 said:

    Except now I need to pass it a Company Number.

    How is this difficult? Start at 1, work your way up. With luck (ha!) you just have to repeat until you get some data. More likely, check each response for data that looks like yours, until you find a match. Then, at your discretion, tell them about the security hole.

    The author of this post takes no responsibility for you getting fired, or you or your employer facing any other penalties, as a result of following this advice, which is not intended seriously and really isn't a good idea because it could expose you to all sorts of privacy violations, especially if any of the data in question involve EU entities or residents.



  • @Scarlet_Manuka said:

    How is this difficult? Start at 1, work your way up. With luck (ha!) you just have to repeat until you get some data. More likely, check each response for data that looks like yours, until you find a match. Then, at your discretion, tell them about the security hole.

    You are not putting any new ideas into my mind- I have considered this.

    I don't know for sure it's a security hole, at least not yet. I do have to pass logininfo, or maybe basicLoginInfo or ExTeNdEdLoGiN or whatever- So they know who I am. Assuming I can only access my own Company Number, it's just stupid and not a security hole.

    I've tried random ones, and I get an error that might mean access denied.



  • Can a single login manage multiple accounts?



  • @ben_lubar said:

    Can a single login manage multiple accounts?

    Don't ruin my bitch session by suggesting that this might make sense.

    I don't know. I got involved with this because the original project team forget to include any developer, and eventually it came to me to give an time estimate on "building a SOAP API". When I realized they meant querying an existing web service, I said an afternoon if you have documentation and a decent design, call it a few days if not. Unknown to me, everyone else they talked to was quoting months.



  • API flexibility. However, in C# it's written like this:

    public string password { get; set; }
    


  • Given that overriding the default get or set behavior simply involves adding an explicit getter or setter, what value does the { get; set; } boilerplate add?


  • sockdevs

    Less boilerplate than writing the get/set yourself :stuck_out_tongue:



  • I might be thick as two short ints but I still don't see the point of writing any of it until you actually need to augment normal get/set behavior, at which point you just explicitly add what you need. What am I missing here?



  • I don't think that you are missing anything. If the semantics are the same, then there is indeed no reason to bother with the more complicated setup.



  • @Magus said:

    s appears to be C# code written by someone who just wrote their first non-Java program.

    There are no partial classes in Java, so no, it's another (they never run out) dumbass C# developer.


  • sockdevs

    @flabdablet said:

    I might be thick as two short ints but I still don't see the point of writing <em>any</em> of it until you actually need to augment normal get/set behavior, at which point you just explicitly add what you need. What am I missing here?

    It could be a property defined by an interface; when you implement the interface, you can override the default get/set if you want, but if you don't, you just { get; set; }.
    It's also very handy for easily doing this: { get; private set; }.



  • Java doesn't have properties, and wouldn't know to auto-redirect from field access to JavaBean method calls, so descendant/future classes are stuck with it until you recompile/rewrite all users.



  • @flabdablet said:

    I might be thick as two short ints but I still don't see the point of writing any of it until you actually need to augment normal get/set behavior, at which point you just explicitly add what you need. What am I missing here?

    Because you are stuck with it forever, and can never change is without breaking existing client code! Cute Kittens and Little children may die as a result!

    hint: You have no knowledge that someone, somewhere has not written code that used GetField(...) on that member.



  • It looks the same, but might work differently under the hood? If the one is direct member access and the other uses (autogenerated) methods, then the ABI might change and you'd need to recompile the referencing classes if you add a getter/setter later.



  • If the compiled code is going to end up in a dll, I guess that's a fair call.



  • @flabdablet said:

    If the compiled code is going to end up in a dll, I guess that's a fair call.

    Even code in an EXE can be loaded and called from another EXE (an EXE is nothing more than a DLL with an special type of entry point when you get down to it).

    So many people do not think about the "O" is solid. Especially the second part... CLOSED TO MODIFICATION.



  • @flabdablet said:

    If the compiled code is going to end up in a dll, I guess that's a fair call.

    Also reflection works differently for fields and properties, so if anyone reflects on your class, their code will break when you later replace a field with a property.

    Also also, fields have limited databinding capability (so for example in WPF you generally need properties all around), probably for the same reason.



  • @Maciejasjmj said:

    reflection works differently for fields and properties, so if anyone reflects on your class, their code will break when you later replace a field with a property.

    There ought to be some way to implement a standard handler for this case that pops up an astonishingly irritating orange toaster complaining that reflection is Doing It Wrong.



  • @flabdablet said:

    There ought to be some way to implement a standard handler for this case that pops up an astonishingly irritating orange toaster complaining that reflection is Doing It Wrong

    Sorry... Reflection is a very common and legitimate technique....unless you also believe that ASP.NET is completely based on "Doing It Wrong".


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.