Unexpected status code: 500

[cyberjoey]

Hi, I've followed the installation instructions and after running foreman start I get the: 14:47:10 web.1 | started with pid 7004 and the webpage is up and running at localhost:5000 Everything looks great and I am presented with a Username and Password feild just like on the XBee heroku webpage. However, when I try to login using credentials that work on my.devicecloud.com, a red box displays on the webpage saying "Unexpected status code: 500" and the powershell console running the local webserver prints out an error and stacktrace that looks like this: 14:40:42 web.1 | [27/Jul/2017 14:40:28] "GET / HTTP/1.1" 200 4314 14:40:42 web.1 | [27/Jul/2017 14:40:28] "GET /api/user HTTP/1.1" 403 59 14:40:42 web.1 | ERROR: Uncaught exception during authentication 14:40:42 web.1 | Traceback (most recent call last): 14:40:42 web.1 | File "C:\Users\Joseph.Shelton\Desktop\XXBee\XBeeZigBeeCloudKit-master\xbgw_dashboard\apps\dashboard\views.py", line 373, in login_user 14:40:42 web.1 | password=password) 14:40:42 web.1 | File "C:\Python27\lib\site-packages\django\contrib\auth\__init__.py", line 60, in authenticate 14:40:42 web.1 | user = backend.authenticate(**credentials) 14:40:42 web.1 | File "C:\Users\Joseph.Shelton\Desktop\XXBee\XBeeZigBeeCloudKit-master\xbgw_dashboard\libs\digi\auth.py", line 64, in authenticate 14:40:42 web.1 | login_valid, resp = conn.authenticate() 14:40:42 web.1 | File "C:\Users\Joseph.Shelton\Desktop\XXBee\XBeeZigBeeCloudKit-master\xbgw_dashboard\libs\digi\devicecloud.py", line 116, in authenticate 14:40:42 web.1 | path_filter="")) 14:40:42 web.1 | File "C:\Users\Joseph.Shelton\Desktop\XXBee\XBeeZigBeeCloudKit-master\xbgw_dashboard\libs\digi\devicecloud.py", line 73, in _get 14:40:42 web.1 | response = self.r.get(*args, **kwargs) 14:40:42 web.1 | File "C:\Python27\lib\site-packages\requests\sessions.py", line 347, in get 14:40:42 web.1 | return self.request('GET', url, **kwargs) 14:40:42 web.1 | File "C:\Python27\lib\site-packages\requests\sessions.py", line 335, in request 14:40:42 web.1 | resp = self.send(prep, **send_kwargs) 14:40:42 web.1 | File "C:\Python27\lib\site-packages\requests\sessions.py", line 438, in send 14:40:42 web.1 | r = adapter.send(request, **kwargs) 14:40:42 web.1 | File "C:\Python27\lib\site-packages\requests\adapters.py", line 331, in send 14:40:42 web.1 | raise SSLError(e) 14:40:42 web.1 | SSLError: [Errno 1] _ssl.c:507: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed SIGINT received

Here is what the login page displaying the 500 status code looks:

I see that it has something to do with the SSL certificate and I also notice that the first two lines say HTTP with no mention of HTTPS. I feel like I am missing something fundamental/obvious and any help here would be greatly appreciated.

[mikewadsten]

You're seeing this error because the SSL certificate for https://login.etherios.com expired a couple of months ago. (Digi sold Etherios a few years ago and we haven't updated every single app and device yet.)

You should be able to get past this if you change xbgw_dashboard/settings.py, line 338, to read "devicecloud.digi.com" or another valid FQDN for Device Cloud.

LIB_DIGI_DEVICECLOUD = {
    # Use '#' as delimeter to parse username/cloud combo strings
    'USERNAME_CLOUD_DELIMETER': '#',
    # Set a default cloud fdqn if not provided
    'DEFAULT_CLOUD_SERVER': 'login.etherios.com',  # <--- this is the problem
}

That being said, I'd recommend you try deploying the app (once you fix the DEFAULT_CLOUD_SERVER value) to Heroku rather than using it locally.

The reason for this is that, to automatically update the values shown in the dashboard, the Cloud Kit application sets up HTTP push monitors in Device Cloud. Device Cloud is not able to "push" data to applications running on your local machine -- in fact, if you log into the local app and go to the dashboard, an error message will pop up in the corner telling you the app couldn't set up the push monitor.

You won't have this issue if you deploy the app on Heroku.

[cyberjoey]

Thank you for your quick response. I made the change you recommended and restarted the local webserver and I still get the same error. I tried 'DEFAULT_CLOUD_SERVER': 'devicecloud.digi.com', and 'DEFAULT_CLOUD_SERVER': 'my.devicecloud.com',

both resulted in the same error. However I have noticed that if I navigate to "http://localhost:5000/#/login/devicecloud.digi.com" or http://localhost:5000/#/login/my.devicecloud.com then I can login and authentication works just fine.

When trying to deploy the app to heroku I kept getting an error saying "invalid response" and "Are you behind a proxy?". I imagine the error has something to do with me being on my work network. But if you have any other ideas regarding why the heroku login/deployment isn't working that would be great.

This is why I wanted to at least start by getting it up locally. I did notice the issue you mentioned with the push monitor not working locally. Sending commands from the dashboard worked fine but I wouldn't see changes going the other way until I refreshed the page.

Do you have any suggestions for why the suggested modification to settings.py isn't making a difference?

[mikewadsten]

Do you have any suggestions for why the suggested modification to settings.py isn't making a difference?

Probably this line in the front-end code: https://github.com/digidotcom/XBeeZigBeeCloudKit/blob/master/src/app/login/login.js#L28 The "Want to access a different cloud?" link (which is actually pointless these days since we switched over to using just a single cloud, instead of Europe vs. US) overrides the server selection for logging in, hence why the navigation as you described worked.

I've never seen an "Are you behind a proxy" error when deploying to Heroku, but a quick Google search turned this up: https://community.c9.io/t/unable-to-login-heroku-behind-proxy/16930

You may want to try updating the Heroku CLI and, if you're using the API directly, be sure you update to v3 as soon as possible to ensure consistent operation!

I might be able to push the updates to get the app away from "Etherios" to the develop branch. It's all been done already for the Wi-Fi Cloud Kit app (from which we forked this app), and the production instance (https://xbeegateway.herokuapp.com) is also updated.

[cyberjoey]

Thanks again for the fast reply. I understand that going to: http://localhost:5000/#/login/my.devicecloud.com overrides the authentication server being used. I got the idea for tying it out by looking at the outdated "Want to access a different cloud?" link.

My question was, why isn't the suggested modification to settings.py making a difference on the default http://localhost:5000/#/login page?

My LIB_DIGI_DEVICECLOUD variable is currently

LIB_DIGI_DEVICECLOUD = {
    # Use '#' as delimeter to parse username/cloud combo strings
    'USERNAME_CLOUD_DELIMETER': '#',
    # Set a default cloud fdqn if not provided
    'DEFAULT_CLOUD_SERVER': 'devicecloud.digi.com',
}

And I still get the same Unexpected Status message.

[mikewadsten]

It isn't making a difference because the front-end code (almost entirely JavaScript-based, and loosely coupled with the backend) has that hard-coded "login.etherios.com" value, while the backend (written in Python, and thus having access to settings.py) only uses DEFAULT_CLOUD_SERVER if the user doesn't supply the cloud_fqdn parameter in the login request.

You can see that code here: https://github.com/digidotcom/XBeeZigBeeCloudKit/blob/master/xbgw_dashboard/apps/dashboard/views.py#L359

    try:
        cloud_fqdn = request.DATA['cloud_fqdn']
    except KeyError:
        if 'DEFAULT_CLOUD_SERVER' in app_settings.LIB_DIGI_DEVICECLOUD:
            cloud_fqdn = app_settings.LIB_DIGI_DEVICECLOUD['DEFAULT_CLOUD_SERVER']
        else:
            return Response(status=status.HTTP_400_BAD_REQUEST)

If you want, you could change those lines to something like this, to force the backend to always use the FQDN specified in settings.py:

cloud_fqdn = app_settings.LIB_DIGI_DEVICECLOUD.get('DEFAULT_CLOUD_SERVER', 'my.devicecloud.com')

Otherwise, I'm about 30% of the way through resolving merge conflicts before I can update the develop branch here with our latest internal code. If you can hang on until then, and switch over to the develop branch at that point, you shouldn't have any more login issues.

Edit: Typos in suggested change

[cyberjoey]

Ah ha! That did the trick. Thanks for all your help mike. I will move to the develop branch once I see your commit. Also just a quick note in case somebody runs into a similar problem: Changing that try/except block on Ln359 as you mentioned to:

cloud_fqdn = app_settings.LIB_DIGI_DEVICECLOUD.get('DEFAULT_CLOUD_SERVER', 'my.devicecloud.com')

is what did it.

---

Edit by mikewadsten: DEFAULT_CLOUD_USER -> DEFAULT_CLOUD_SERVER, which is what I had meant to type the first time

[mikewadsten]

@cyberjoey I've pushed the changes on the develop branch. Give that a try and let me know if anything breaks in catastrophic ways. :)

[cyberjoey]

Hey mike, I switched to the develop branch and noticed a few issues. First, in regards to the issue we were talking about above, the "Unexpected status code: 500" is happening on the develop branch. Even stranger, changing the url to ..."#/login/my.devicecloud.com" or something similar actually doesn't mitigate the issue as it did previously. I can see that you did change the settings.py file to my.devicecloud.com but I don't see the exact changes to views.py that we discussed. I will try to change views.py and see if I get different behavior.

Also, it's probably good to mention that I forked the develop branch and deployed it to heroku successfully. In the process I noticed a few problems with the instructions regarding the buildpacks. The instructions for heroku deployement in readme.md have a typo:

$ heroku buildpacks:add hhttps://github.com/heroku/heroku-buildpack-pgbouncer.git

should be:

$ heroku buildpacks:add https://github.com/heroku/heroku-buildpack-pgbouncer.git

Also, more importantly, I think the python buildpack should use python 2.7 but since a runtime.txt file is not present it defaults to python 3.6.2 and the push/deployement to heroku fails because of a python syntax error.

After forking the branch and adding the runtime.txt file to use the python 2.7.13 buildpack, deployment is successful.

[cyberjoey]

My apologies. I mistakenly didn't provision the database after deploying. Running:

heroku run python manage.py syncdb

Fixed the "Unexpected Status Code: 500" error.

So everything works great on the development branch except the small problem with the build packs.