XACARS Position Reports

[XTerminator24]

I'm currently the technical lead for what is currently an X-Plane only VA. We currently support Mac users by using XACARS. Our current VA system is custom built. We were looking at expanding our VA to support more than just X-Plane. During that process I started taking a look at phpVMS as a potential replacement for our current custom built solution.

 

I'm pretty happy with the evaluation of phpVMS 7 so far. When it comes to XACARS logging I did run into an issue that I assume others have seen and I'm wondering what the best approach is to solve it.

 

The way I have things configured is that XACARS talks to a few php pages outside of phpVMS.

I then use the phpVMS API as per the documentation http://docs.phpvms.net/developers/acars to retrieve and store the data as required.

I have been using the user's API Key in the Password field of XACARS.

 

The issue that I've come across is that XACARS does not send the "password" (in my case the API key) for all messages. This results in me having a position report but no way to add the "X-API-Key" to the header before making the API call. Trying to update the position information by executing a POST to /api/pireps/acars/position requires the API Key of the user who owns the flight. Hard coding the API Key of an Admin results in a 503 Unauthorized. I'm assuming the only user able to update a position report through that API endpoint is the user identified by the "user_id" in the pirep. I also attempted to store the APIKey in the $_SESSION or $_COOKIE but the X-Plane plugin communicates to the server in a way that those are inaccessible.

 

I have 2 things that I've thought about doing to try and overcome this obstacle:

1. Create a table in a second database. When the prefile is completed by the user through the API, store the pirep_id and the api_key in a table. When XACARS sends data that doesn't contain the user password (in my case the API Key), run a query on that table using the pirep_id to figure out the api_key. Once the flight is completed, I can delete the record from the table.
2. The second option I'm wondering about would be to create an addon for XACARS pirep processing. I'm assuming that would allow me to create the required endpoints while still having the ability to store data in the database without needing the API Key as I do now trying to process through the API

 

Overall I'm really impressed but would like some feedback on what other's think is the best approach for this type of issue. How are others using XACARS processing their position reports?

 

 

Edited August 11, 2020 by XTerminator24
repair a link

[Strider]

I dont think xacars works with phpvms v7. There is one other freeware acars that works, but since phpvms v7 is only in beta all but one acars developers are not supporting phpvms v7 yet.

[XTerminator24]

I'm very familiar with the XACARS protocol and am capable of writing a connector myself using the documented phpVMS API. I've actually got the majority of the requirements completed already. We have maintained a custom connector for our own system for well over 10 years. The position reports are my only sticking point right now, which I'm confident I can work around. I'm just looking for some technical advise on whether the preferred method would be storing temporary state information in a secondary table/database or by developing an addon. I realize phpVMS 7 is in beta but with us doing an evaluation for a potential future move to a new system, it doesn't make sense for us to evaluate phpVMS 5, which to my understanding, is no longer receiving updates. In order to properly do that evaluation, I need to make sure all the infrastructure we require is capable of interfacing with phpVMS (ie/ Can we make the only Mac client available work).

[ProAvia]

Hopefully you come up with a viable solution. If you do, any chance you will share it with the community?

 

Do you have a present solution that works with PHP 7.2 and phpVMS 5.5.2.72?

[XTerminator24]

I discussed with @Nabeel on Discord. He gave me a pretty good workaround of combining both the flight_id and api_key back to the XACARS client on the begin flight. That way, each subsequent message from XACARS is sending both the flight_id and api_key in a single data field. I then parse that field to break it into the 2 pieces. I did some initial testing and it looks like it's going to work beautifully.

 

My current solution is not in a place to be shared yet. But with time I can certainly share what I come up with. My solution will be for PHP 7.3 (it will probably work with 7.2 as well) and phpVMS 7. I don't see our airline moving from our current custom built solution to phpVMS 5. Technically, with the API that has been provided with phpVMS 7, it shouldn't be too hard to integrate any client using a proxy like this as long as you know the formats of the incoming data.