IBM/openapi-to-graphql

Problematic desanitization

Open

#274 opened on Nov 23, 2019

View on GitHub
 (0 comments) (2 reactions) (0 assignees)TypeScript (215 forks)github user discovery
bughelp wanted

Repository metrics

Stars
 (1,645 stars)
PR merge metrics
 (No merged PRs in 30d)

Description

Drawn from #266

As you may be aware of, OtG sanitizes strings from the OAS and then reverses the process where necessary in order to make the appropriate call. Unfortunately, some users have begun reporting problems because the method we use to do this is not waterproof.

The method we currently use is, honestly, a bit primitive. The summarize, we have a map named saneMap that correlates sanitized strings with their raw versions. There are a few places where we store strings but most of time, it happens here, where we recursively analyze the different schemas that are used in the OAS.

This current method is a problem because we arbitrarily dumping all of the sanitized and raw strings into the same place without making any effort to consider their contexts. Therefore, when we actually try to desanitize the strings here, we encounter problems.

We went with this method because the "right" way to do it is complex and this was a more reasonable solution during our prototyping phase. I think the right way to do it would be to create a map for GraphQL (input) object type names, and multiple maps for field names in each of those GraphQL (input) object types.

However, I'm not sure if I have the time to make all the changes needed. If you would like to help, or anyone else, I would be happy to assist. I think for now, we can at least create two separate maps for GraphQL (input) object type names and one for field names. I believe this strategy will solve a significant percentage of possible conflicts by itself.

Contributor guide