rCell – multiple users and weird design choices

Home › Forums › General › rCell – multiple users and weird design choices

Tagged: 

Viewing 20 posts - 1 through 20 (of 20 total)
  • Author
    Posts
  • December 5, 2017 at 8:00 am #22005
    Steve van der Burg
    Participant

    I’m just getting started with my company’s rCell 100. We have three more on order and I plan to make a pool of four of them to spread the load when doing mass SMS to staff as part of a notification system.

    After getting everything going on a dev server, I am successfully logging into the REST service and saving the token that I get back. Yesterday I copied my code to what will become our production server and to my surprise the login code failed. The REST service gave back a “user is logged in from a different IP address” error.

    This is the latest in a bunch of bizarre design choices that I have seen in the auth/authz for this server’s REST service. First of all, this is a _server_, and as such should expect to be contacted from lots of devices on the network all at once. Tying a user/login to an IP address is just the wrong thing to do.

    Can we get this fixed?

    Thanks,
    …Steve

    p.s. I just saw this thread rCell 100 keeps forgetting users and although that looks like it could help me here (I could create one user for dev, one for prod, etc), if the users don’t persist across reboots they’re not that useful.

    December 5, 2017 at 12:50 pm #22009
    Jeff Hatch
    Keymaster

    Steve,

    Actually, this behavior is quite common (not wanting the same user to be logged in from two IPs) on a lot of products. For instance, gmail will notify you when you log in from an IP that it doesn’t recognize. The key is to log out from the first IP when you are finished with your request. See:

    Logging Out

    On the other hand, MTR 4.0 that is going to be released in Q1 will have multiple user support, so you can create multiple users that will persist in the MTR API database.

    Jeff

    December 5, 2017 at 12:55 pm #22010
    Steve van der Burg
    Participant

    Gmail is built for users (ie. people) to hit via their web browsers. The use case is completely different than that of a REST service!

    I’m looking forward to multiple user support, but I think you should seriously consider dropping the “tie a user to an IP address” restriction. It adds nothing to the product and adds complications to anyone developing for it.

    December 5, 2017 at 3:16 pm #22011
    Jeff Hatch
    Keymaster

    Steve,

    The Web UI uses the same “REST service” in that it is the same daemon, same code, same requests. That said, I understand your point. The limitation is that there are more than two ways that the API is used on the MTR, but the central focus was on the Web UI. In that case it is users hitting it via their web browsers. On a device like the MTR (embedded industrial router) there will be a limited number of services and functionality will be combined together like in this case.

    The IP restriction will remain unless we (Multitech) can figure out a way to differentiate between browser traffic and clients hitting the API from a non-browser app. I’m sure there are ways to do this. On the other hand, it may be that we decide to drop the IP limitation.

    Jeff

    March 15, 2018 at 8:02 am #22847
    Steve van der Burg
    Participant

    Is there any news on this?

    March 15, 2018 at 8:45 am #22850
    Jeff Hatch
    Keymaster

    Steve,

    There is now support for multiple different users in the MTR 4.0.5 release. There are still some limitations on multiple concurrent user sessions, etc., however you can now log in with different users. I’m not sure whether the IP restriction has been removed or not.

    Jeff

    March 29, 2018 at 1:18 pm #22964
    Steve van der Burg
    Participant

    That sounds good, but so far I can’t even tell which (if any) of the files in the downloads area corresponds to MTR 4.0.5. It’s firmware for a Mulitconnect rCell 100 that I need. The firmware update tab in the web UI says “MTR-LAT1 Firmware3.7.3” is currently installed.

    For that matter, which forum here corresponds to my hardware? None of the names clearly match the product.

    Any help would be appreciated.

    March 29, 2018 at 2:07 pm #22969
    Jeff Hatch
    Keymaster

    Steve,

    One way to make sure that you have the correct firmware to upgrade is to file a support portal case at https://support.multitech.com/support. I believe what you’re looking for can be downloaded from https://www.multitech.com/models/92507399LF under the DOWNLOADS drop-down menu.

    Jeff

    March 29, 2018 at 2:11 pm #22970
    Steve van der Burg
    Participant

    That looks like it. Thanks for your help!

    March 29, 2018 at 2:29 pm #22971
    Steve van der Burg
    Participant

    Actually, before I upgrade one of my modems, I would really like clarification on some of your statements. I read the 4.0.5 and it doesn’t mention multiple users or concurrent sessions anywhere. After reading it, it seems that I’ll be able to name my single user “bob” instead of “admin”, but my plan here would be to create 3 users (“prod”,”dev”,”demo”) and have each tied to a different host, with all 3 simultaneously logged in.

    Maybe somebody already using 4.0.5 can confirm that this is possible?

    April 2, 2018 at 10:43 am #22976
    Jeff Hatch
    Keymaster

    Steve,

    There was a sales announcement here (though I can see the confusion about the multiple user support):

    https://www.multitech.com/documents/publications/sales-flyers/PCN%20030818-00_MTR%20SW%204.0.5%20release_post_2.pdf

    The following link is the User Manual (See Chapter 12 for user administration information):

    https://www.multitech.com/documents/publications/manuals/s000566.pdf

    On MTR 4.0.5 you can add three different users (even more if you want to). As for the simultaneous login of three different users, I have not tested that so I cannot confirm that is fully supported.

    Jeff

    April 4, 2018 at 3:17 pm #22999
    Steve van der Burg
    Participant

    Thanks so much for all of your help so far. I have another question now about the sms_send REST endpoint. I see that it can take a list of recipients (numbers).

    Any idea if there’s a limit on the size of that list? If I want to put 1000 numbers in there, will the modem send them?

    And do we have any idea at what rate?

    And will the modem queue additional requests while it’s completing a large one (like my “send to 1000 numbers” example)?

    I really can’t bother 1000 people by testing some of this stuff out, so if the developers have information on some or all of it, it would help me out greatly.

    Thanks again,
    …Steve

    April 4, 2018 at 3:47 pm #23001
    Jeff Hatch
    Keymaster

    Steve,

    The max number of recipients is 100. Not sure that is documented anywhere. As for the rate, that would have to be empirically tested. It depends on the radio, provider, signal, how busy the Conduit is, and whether the provider is throttling or not.

    I do not have any information on whether it will queue up requests or be able to handle things in any sort of batch mode.

    Jeff

    April 4, 2018 at 3:49 pm #23002
    Jeff Hatch
    Keymaster

    I should have said MTR in the previous statement.

    March 20, 2019 at 1:07 pm #27487
    Steve van der Burg
    Participant

    I see now that there’s version 4.1.0 of the firmware out. I had to guess at the URL of its change log (based on the 4.0.5 one that you gave me) and in it I see this:

    – Certain version 1 API (/api/v1) calls do not work.

    That’s a pretty scary line to come across. Can you refer me to documentation for the API version that 4.1.0 uses? I can’t seem to find that anywhere either.

    And it looks like the same basic issues still exist:

    – A misunderstanding of how REST should work. It should be stateless, and not have a notion of “logging in” or “logging out”. And it certainly shouldn’t tie a user to a connecting IP address.
    – The API for SMS send should return a unique identifier for each request, and another call should return status on the message with that identifier.

    Do you know if any development work is going on that would address either of these?

    Thanks,

    …Steve

    March 20, 2019 at 1:48 pm #27488
    Jeff Hatch
    Keymaster

    Steve,

    I see the item you are talking about and have asked the authors of the release notes about it.

    As for your definition of how REST should work, I will respectfully disagree with you. I have worked with REST APIs on several Enterprise products including a firewall and a Storage Area Network controller. Due to security and other things, any changes to the device configuration must be recorded as being done by some user on the device (or in Active Dircectory or an LDAP database). There must be at least some AUTHN and accounting via some sort of session to accomplish this. The “logging out” is a limitation of this particular API (one must log out in order to log in from a different computer). Other APIs that I have worked on for devices similar to this one behave in much the same way.

    The “tying” of a user to a network address is antiquated. It is an attempt to prevent man-in-the-middle if nothing else.

    There is no development work being done to address these that I know of. The best place to be making enhancement requests would be at https://support.multitech.com where they can take your requests and forward them on to engineering.

    Jeff

    March 22, 2019 at 7:26 am #27494
    Steve van der Burg
    Participant

    I’m not saying that the REST calls shouldn’t be associated with a user. I’m saying that requiring a “log in” REST call that then ties the logged-in user to an IP address is wrong. REST is supposed to be stateless, so I should be able to submit credentials with any REST call and have it work.

    But tying a user to an address and not supplying a unique ID for a message submitted for sending (so that its status can be reliably looked up later) are the real deal breakers for us. We’ve tried for a year, but we are unable to build a reliable service on top of these modems because of those issues.

    …Steve

    March 22, 2019 at 7:53 am #27495
    Jeff Hatch
    Keymaster

    Bad enough that credentials are passed between client and server once. Every time is a bit much.

    March 22, 2019 at 7:55 am #27496
    Steve van der Burg
    Participant

    That’s only bad if they’re being passed in the clear. As long as the requests and responses are encrypted in transit, you’re fine.

    It’s not like I’m describing something unique or new or odd — every other REST API works that way.

    March 22, 2019 at 8:12 am #27497
    Jeff Hatch
    Keymaster

    Actually, according to certifications and certain industry standards, having it encrypted inside SSL is not enough. Also, this API has a dual purpose that supports a Web UI with authorizations that determine what the user can see and what they can do. The token-based approach that is being used in this API is the same as is used across industries.

    Ideally, user credentials (username/password) should never be passed across when accessing a device. Authentication should be handled with protocols like kerberos with active directory or LDAP in Unix. If the password is hashed, it might be acceptable to some of the new standards.

    That said, from what you have said, you will not like where security requirements for these types of devices are headed. Ease of use of APIs is going to start getting to be more painful.

  • Author
    Posts
Viewing 20 posts - 1 through 20 (of 20 total)
  • You must be logged in to reply to this topic.