add hideCompletAppIdAndClientKey

[catalunha]

New Feature / Enhancement Checklist

• [x ] I am not disclosing a vulnerability.
• [x ] I am not just asking a question.
• [x ] I have searched through existing issues.

Current Limitation

When we configure Parse().initialize(...,debug:true) Parse_SDK_Dart/Flutter exposes the complete appId and clientKey in the request log as seen below:

╭-- Parse Request
curl -X GET -H 'user-agent: Flutter Parse SDK 3.1.2' -H 'X-Parse-Application-Id: x4uHx8hJECTwerwwewrw32342fsdcsdfw23422sd' -H 'X-Parse-Client-Key: GoHjfXQ1fICwrfcse23423fcsdcdsfwer32rsdcs' https://parseapi.back4app.com/health

 https://parseapi.back4app.com/health
╰--

But note that this exposes the complete appId and clientKey which is enough information for anyone to access the database and perform some operations.

When we are making tutorials or sharing these logs with a friend for studies, this information is also attached and we need to rectify it all the time.

In the case of videos, it is impossible to view the degub and hide this information on all screens.

Feature / Enhancement Description

To resolve this I forked Parse_SDK_Flutter and added the hideCompletAppIdAndClientKey attribute to Parse().initialize(...) which is false by default.

So if I need to see the output of requests and responses but want to hide the appId and clientKey, which is always true, I just configure

Parse().initialize(...,debug:true,hideCompletAppIdAndClientKey:true) so my output is now:

╭-- Parse Request
curl -X GET -H 'user-agent: Flutter Parse SDK 3.1.2' -H 'X-Parse-Application-Id: x4uHx...' -H 'X-Parse-Client-Key: GoHjf...' https://parseapi.back4app.com/health

 https://parseapi.back4app.com/health
╰--

The classes impacted with my feature were done in the fork were packages/dart/lib/parse_server_sdk.dart

Future<Parse> initialize({
   bool hideCompletAppIdAndClientKey = false,
});

packages/dart/lib/src/data/parse_core_data.dart

static Future<void> init({
   required bool hideCompletAppIdAndClientKey,
});

packages/dart/lib/src/network/parse_http_client.dart

void _logCUrl(http.BaseRequest request) {
       if (parseCoreData.hideCompletAppIdAndClientKey &&
           (name == keyHeaderApplicationId || name == keyHeaderClientKey)) {
         curlCmd += ' -H \'$name: ${value.substring(0, 5)}...\'';
       } else {
         curlCmd += ' -H \'$name: $value\'';
       }
}

I hope this resource is approved as it will really facilitate the exchange of information and the preparation of tutorial videos. As is my current case.

The change did not affect classes with Dio. Because it's really not my current situation. But it would just edit the packages/dart/lib/src/network/parse_dio_client.dart class with the same condition.

I didn't prepare a Pull Request because I'm waiting for your suggestion.

Congratulations to everyone who has the knowledge to cooperate with free software.

Example Use Case

With hideCompletAppIdAndClientKey default false i.e. Parse().initialize(...,debug:true);

╭-- Parse Request
curl -X GET -H 'user-agent: Flutter Parse SDK 3.1.2' -H 'X-Parse-Application-Id: x4uHx8hJECTwerwwewrw32342fsdcsdfw23422sd' -H 'X-Parse-Client-Key: GoHjfXQ1fICwrfcse23423fcsdcdsfwer32rsdcs' back4app.com/health

  https://parseapi.back4app.com/health
╰--

With hideCompletAppIdAndClientKey =true i.e. Parse().initialize(...,debug:true,hideCompletAppIdAndClientKey: true);

╭-- Parse Request
curl -X GET -H 'user-agent: Flutter Parse SDK 3.1.2' -H 'X-Parse-Application-Id: x4uHx...' -H 'X-Parse-Client-Key: GoHjf...' back4app.com/health

  https://parseapi.back4app.com/health
╰--

Alternatives / Workarounds

When sending a debug to a friend delete or change the appId and clientKey manually. Or in video editing every moment they appear. Which is really unbelievable.

[parse-github-assistant[bot]]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[mtrezza]

You are setting debug: true, you are expecting to see more information than usual. Introducing another option to partly "overrule" the debug option already indicates that there is something strange about this approach. I'm not sure that "making video tutorials" is really a feature argument here. That seems to have more to do with how tutorial videos are edited and which information is hidden with whatever video editing technique you choose. What we commonly see is that sensitive information is either made unreadable, or the information is just dummy or ephemeral information that can be shared freely.

If you are using a permanent environment for making tutorials maybe it's good to rethink your strategy. You can never be sure that for a glimpse of a second some sensitive information will be revealed and you may overlook that. So even if your suggested option was implemented, imagine you scroll through the code where these values are defined and then you publish the video without noticing it. In short - this PR doesn't seem to solve your original concern.

[mbfakourii]

You are setting debug: true, you are expecting to see more information than usual. Introducing another option to partly "overrule" the debug option already indicates that there is something strange about this approach. I'm not sure that "making video tutorials" is really a feature argument here. That seems to have more to do with how tutorial videos are edited and which information is hidden with whatever video editing technique you choose. What we commonly see is that sensitive information is either made unreadable, or the information is just dummy or ephemeral information that can be shared freely.

If you are using a permanent environment for making tutorials maybe it's good to rethink your strategy. You can never be sure that for a glimpse of a second some sensitive information will be revealed and you may overlook that. So even if your suggested option was implemented, imagine you scroll through the code where these values are defined and then you publish the video without noticing it. In short - this PR doesn't seem to solve your original concern.

@catalunha and it is also possible to change the keys after training from the parse dashboard ! parse dashboard > App Settings > Server Settings > Core Settings > SETTINGS > EDIT DETAILS

[catalunha]

Thank you for your contributions @mbfakourii

Another scenario I also have here and this resource would help I describe below. I have 4 independent applications accessing the same database. To avoid a monolithic and serve different sectors and teams. In these I use resources like dotenv to hide the keys and they are not in debug mode.

In addition to these 4 I have the app for direct testing of some modules that I develop and implement in each one when necessary. It is a family project, small and under construction. But it is a real scenario.

In this test app I always need to share some debugs for troubleshooting.

If I need to send forums, slack, tickets, stackoverflow, etc every round of tests and debugs, I have to access dashboard > App Settings > Server Settings > Core Settings > SETTINGS > EDIT DETAILS, get new credentials and go to the other 4 modules to change the AppId and ClientKey will become a difficult task.

And in debug what I'm most interested in are the request constructions and the responses and not the sensitive credential information.

[catalunha]

My suggestion can be tested and seen here. https://github.com/catalunha/Parse-SDK-Flutter

[RodrigoSMarques]

My opinion.

I agree with the @mtrezza.

It's a very specific use case.

In a final version application, you will not use debug=true

If you made the changes in your FORK, use it in your use case and the final version for a production application.

Note: AppId and ClientKey are not sensitive credentials.

With any reverse engineering tool, you have access to keys in your application's code.

Your application security must be based on ACL's and CLP's.

This is what protects your application from misuse.

The masterkey is sensitive.

[catalunha]

Thanks. If you wish, you can close the issue/feature.