vingerha / gtfs2

Support GTFS in Home Assistant GUI-only
https://github.com/vingerha/gtfs2
MIT License
65 stars 4 forks source link

Authentication Fails for GTFS RT for WMATA (Washington, DC) #21

Closed davidallen353 closed 4 months ago

davidallen353 commented 4 months ago

BLUF: gtfs_rt_helper is not sending API key correctly

Does not download data for either Metro bus and Metro rail GTFS RT services.

For the setup, I use the following URLs: Rail https://api.wmata.com/gtfs/rail-gtfsrt-tripupdates.pb https://api.wmata.com/gtfs/rail-gtfsrt-vehiclepositions.pb https://api.wmata.com/gtfs/rail-gtfsrt-alerts.pb

Bus https://api.wmata.com/gtfs/bus-gtfsrt-tripupdates.pb https://api.wmata.com/gtfs/bus-gtfsrt-vehiclepositions.pb https://api.wmata.com/gtfs/bus-gtfsrt-alerts.pb

I also include my API key for both. I have attempted to include is as either an API key or an X_API key.

It fails to update an the log includes the following message:

2024-02-25 18:50:05.472 DEBUG (SyncWorker_15) [custom_components.gtfs2.gtfs_rt_helper] GTFS RT get_feed_entities for url: https://api.wmata.com/gtfs/rail-gtfsrt-vehiclepositions.pb , headers: {'Authorization': 'MY_API_KEY'}, label: vehicle positions

2024-02-25 18:50:05.584 DEBUG (SyncWorker_15) [custom_components.gtfs2.gtfs_rt_helper] Updating vehicle positions, and got: 401 for: b'{ "statusCode": 401, "message": "Access denied due to missing subscription key. Make sure to include subscription key when making requests to an API." }'

As a debugging step, I attempted to include the API key in the URL (and not in the API key field in the GUI). That is, I set the URL as https://api.wmata.com/gtfs/rail-gtfsrt-tripupdates.pb?api_key=MY_API_KEY which yielded a similar but different error:

2024-02-25 18:37:56.464 DEBUG (SyncWorker_3) [custom_components.gtfs2.gtfs_rt_helper] GTFS RT get_feed_entities for url: https://api.wmata.com/gtfs/rail-gtfsrt-vehiclepositions.pb?api_key=MY_API_KEY , headers: {'Authorization': 'na'}, label: vehicle positions

2024-02-25 18:37:56.739 DEBUG (SyncWorker_3) [custom_components.gtfs2.gtfs_rt_helper] Updating vehicle positions, and got: 400 for: b'\xef\xbb\xbf<?xml version="1.0" encoding="utf-8"?>\n<Error><Code>InvalidAuthenticationInfo</Code><Message>Authentication information is not given in the correct format. Check the value of Authorization header.\nRequestId:ed961e62-801e-0016-0b43-68b186000000\nTime:2024-02-25T23:37:56.7314882Z</Message></Error>'

So it appears that it attempted to pass "na" as the API key while the API expects a hex string.

I confirmed that going to the URL https://api.wmata.com/gtfs/rail-gtfsrt-tripupdates.pb?api_key=MY_API_KEY returns the expected file.

Release used gtfs2 v0.3.6 and HAOS

vingerha commented 4 months ago

I will have a look but not sure if I should cry ot laugh as to yet-another-new approach where even the static data requires a key. Of those tested I only had 1 case where the realtime data required a key and this I understand as it is to protect mis/over-use...but for static???? why ??? Anywho ...will get back

vingerha commented 4 months ago

I discovered I am using different methods to get realtime data which apparently donot always work the same esp. when api_key apply The workaround I have is that you use the gtfs rt service call to get the data locally, this with your url incl. api_key and then from the sensor you refer to that local file, see doc. I cannot verify if the rt data contains any valid stuff for bussses/trains...too much work but at least the file is read without any issues now

davidallen353 commented 4 months ago

I did manage to pull the static data by adding ?api_data='MY_API_KEY' to the end of the URL. But when I tried doing the same for the real time data, it appears to be trying to add "na" as an API key.

Perhaps a checkbox to enable/disable authentication in the realtime setup (so you can add the API key to the URL) could be a decent work around.

I will try setting up a service this evening to see if that works.

vingerha commented 4 months ago

It wokrs for me but only via the service call, not (!) via the sensor setup...from the sensor I refer to the local created file by the service call

vingerha commented 4 months ago

Whilst the workaround is fine (at my end) I will try to allow different locations for the key from theregular configuration. It now just assumes it to be part of a header but I will add url/querystrin for this one

EDIT: prototype is working image

jpenyc commented 4 months ago

Got here searching trying to make it work. NYC MTA requires api-key as well. https://api.mta.info/#/HelpDocument looking forward to the addition as in the screenshot above to make it work.

vingerha commented 4 months ago

Got here searching trying to make it work. NYC MTA requires api-key as well. https://api.mta.info/#/HelpDocument looking forward to the addition as in the screenshot above to make it work.

You need static data first to make real-time work, which source are you using for static? And... the x-api-key should already work in the current setup

EDIT: correction... X_API_KEY does not work, will review too

vingerha commented 4 months ago

Both fixed in 0.3.8

EDIT: