rCell – multiple users and weird design choices

[Steve van der Burg]

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.

• This topic was modified 6 years, 4 months ago by Steve van der Burg.
• This topic was modified 6 years, 4 months ago by Steve van der Burg.

[Jeff Hatch]

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:

http://www.multitech.net/developer/software/mtr-software/mtr-api-reference/rcell_api_requests/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

[Steve van der Burg]

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.

[Jeff Hatch]

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

[Steve van der Burg]

Is there any news on this?

[Jeff Hatch]

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

[Steve van der Burg]

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.

[Jeff Hatch]

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

[Steve van der Burg]

That looks like it. Thanks for your help!

[Steve van der Burg]

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?

[Jeff Hatch]

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

[Steve van der Burg]

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

[Jeff Hatch]

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

[Jeff Hatch]

I should have said MTR in the previous statement.

[Steve van der Burg]

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

[Jeff Hatch]

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

[Steve van der Burg]

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

[Jeff Hatch]

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

[Steve van der Burg]

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.

[Jeff Hatch]

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