Google Data Studio Community Connector - How to share credentials to 3rd party endpoint accross multiple...











up vote
1
down vote

favorite












I'm developing a custom community connector for the Google Data Studio with the potential goal of publishing it for other users.



Basically it connects to an external REST endpoint, requests data in accordance to what the user has configured in the data source GUI, receives the data and transforms it so that the Google Data Studio can process it.

The connector is using the AuthType USER_PASS. Therefore, when the Google User is creating a data source from that connector, he will be asked for a user/password combination to be used to authenticate at that external REST endpoint. It looks somewhat like this:



Authenticate using <code>USER_PASS</code>



However, consider this scenario:



Google User A creates the data source out of the connector.




  1. He is configuring that data source to authenticate to the external service with the username user and the password password.

  2. He creates a report using that data source.

  3. And then another report.

  4. And then maybe another.

  5. He shares one of these reports with someone else


Now, Google User B receives an E-Mail which tells him there is a report he can view. He clicks on the link. Immediately, the getData() is being called. But it might not be, I didn't quite understand how the caching works. Maybe he is allowed to edit the report. So he does. After a significant change made to that report by B, getData() is being called anyway. But the data source wouldn't know which credentials it should use to authenticate to the external REST endpoint.



I played around with the various CacheServices and PropertiesServices to store that information. I've learned that Cache and Properties are basically the same with the exception that the Cache has a limited lifespan before it expires.




  • The DocumentProperties/DocumentCache is always null, because as I understand it it is not intended to be used from a connector.

  • The ScriptProperties/ScriptCache is shared across all instances of the connector, as in all data sources using that connector. Which is too restricted as maybe a user wishes to use that connector for multiple accounts for that REST API of that external service.

  • The UserProperties/UserCache is too limited, as it is different for Google User A and Google User B.


So the question is:
Where should I store user and password to authenticate that instance of the connector to the external REST service?










share|improve this question




























    up vote
    1
    down vote

    favorite












    I'm developing a custom community connector for the Google Data Studio with the potential goal of publishing it for other users.



    Basically it connects to an external REST endpoint, requests data in accordance to what the user has configured in the data source GUI, receives the data and transforms it so that the Google Data Studio can process it.

    The connector is using the AuthType USER_PASS. Therefore, when the Google User is creating a data source from that connector, he will be asked for a user/password combination to be used to authenticate at that external REST endpoint. It looks somewhat like this:



    Authenticate using <code>USER_PASS</code>



    However, consider this scenario:



    Google User A creates the data source out of the connector.




    1. He is configuring that data source to authenticate to the external service with the username user and the password password.

    2. He creates a report using that data source.

    3. And then another report.

    4. And then maybe another.

    5. He shares one of these reports with someone else


    Now, Google User B receives an E-Mail which tells him there is a report he can view. He clicks on the link. Immediately, the getData() is being called. But it might not be, I didn't quite understand how the caching works. Maybe he is allowed to edit the report. So he does. After a significant change made to that report by B, getData() is being called anyway. But the data source wouldn't know which credentials it should use to authenticate to the external REST endpoint.



    I played around with the various CacheServices and PropertiesServices to store that information. I've learned that Cache and Properties are basically the same with the exception that the Cache has a limited lifespan before it expires.




    • The DocumentProperties/DocumentCache is always null, because as I understand it it is not intended to be used from a connector.

    • The ScriptProperties/ScriptCache is shared across all instances of the connector, as in all data sources using that connector. Which is too restricted as maybe a user wishes to use that connector for multiple accounts for that REST API of that external service.

    • The UserProperties/UserCache is too limited, as it is different for Google User A and Google User B.


    So the question is:
    Where should I store user and password to authenticate that instance of the connector to the external REST service?










    share|improve this question


























      up vote
      1
      down vote

      favorite









      up vote
      1
      down vote

      favorite











      I'm developing a custom community connector for the Google Data Studio with the potential goal of publishing it for other users.



      Basically it connects to an external REST endpoint, requests data in accordance to what the user has configured in the data source GUI, receives the data and transforms it so that the Google Data Studio can process it.

      The connector is using the AuthType USER_PASS. Therefore, when the Google User is creating a data source from that connector, he will be asked for a user/password combination to be used to authenticate at that external REST endpoint. It looks somewhat like this:



      Authenticate using <code>USER_PASS</code>



      However, consider this scenario:



      Google User A creates the data source out of the connector.




      1. He is configuring that data source to authenticate to the external service with the username user and the password password.

      2. He creates a report using that data source.

      3. And then another report.

      4. And then maybe another.

      5. He shares one of these reports with someone else


      Now, Google User B receives an E-Mail which tells him there is a report he can view. He clicks on the link. Immediately, the getData() is being called. But it might not be, I didn't quite understand how the caching works. Maybe he is allowed to edit the report. So he does. After a significant change made to that report by B, getData() is being called anyway. But the data source wouldn't know which credentials it should use to authenticate to the external REST endpoint.



      I played around with the various CacheServices and PropertiesServices to store that information. I've learned that Cache and Properties are basically the same with the exception that the Cache has a limited lifespan before it expires.




      • The DocumentProperties/DocumentCache is always null, because as I understand it it is not intended to be used from a connector.

      • The ScriptProperties/ScriptCache is shared across all instances of the connector, as in all data sources using that connector. Which is too restricted as maybe a user wishes to use that connector for multiple accounts for that REST API of that external service.

      • The UserProperties/UserCache is too limited, as it is different for Google User A and Google User B.


      So the question is:
      Where should I store user and password to authenticate that instance of the connector to the external REST service?










      share|improve this question















      I'm developing a custom community connector for the Google Data Studio with the potential goal of publishing it for other users.



      Basically it connects to an external REST endpoint, requests data in accordance to what the user has configured in the data source GUI, receives the data and transforms it so that the Google Data Studio can process it.

      The connector is using the AuthType USER_PASS. Therefore, when the Google User is creating a data source from that connector, he will be asked for a user/password combination to be used to authenticate at that external REST endpoint. It looks somewhat like this:



      Authenticate using <code>USER_PASS</code>



      However, consider this scenario:



      Google User A creates the data source out of the connector.




      1. He is configuring that data source to authenticate to the external service with the username user and the password password.

      2. He creates a report using that data source.

      3. And then another report.

      4. And then maybe another.

      5. He shares one of these reports with someone else


      Now, Google User B receives an E-Mail which tells him there is a report he can view. He clicks on the link. Immediately, the getData() is being called. But it might not be, I didn't quite understand how the caching works. Maybe he is allowed to edit the report. So he does. After a significant change made to that report by B, getData() is being called anyway. But the data source wouldn't know which credentials it should use to authenticate to the external REST endpoint.



      I played around with the various CacheServices and PropertiesServices to store that information. I've learned that Cache and Properties are basically the same with the exception that the Cache has a limited lifespan before it expires.




      • The DocumentProperties/DocumentCache is always null, because as I understand it it is not intended to be used from a connector.

      • The ScriptProperties/ScriptCache is shared across all instances of the connector, as in all data sources using that connector. Which is too restricted as maybe a user wishes to use that connector for multiple accounts for that REST API of that external service.

      • The UserProperties/UserCache is too limited, as it is different for Google User A and Google User B.


      So the question is:
      Where should I store user and password to authenticate that instance of the connector to the external REST service?







      google-apps-script google-data-studio






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 8 at 9:28

























      asked Nov 8 at 9:19









      Gregor Sondermeier

      415




      415
























          1 Answer
          1






          active

          oldest

          votes

















          up vote
          1
          down vote













          I got inspired by Session.getEffectiveUser(), which is different depending on the user under whose authority the script is running.



          After some testing with a 2nd Google Account I shared a report with, I come to the conclusion that the UserProperties/UserCache behave differently, depending on the option that the report's creator has chosen on whose credentials access should be used. There is a guide about this here.



          Basically, if you choose "Owner's credentials access", which is the default, the UserProperties/UserCache of the creator are being shared with every other viewer. Whereas if you choose "Viewer's credentials access" the UserProperties/UserCache of the current viewer are used.



          This means that if you store the credentials in the creator's UserProperties, which I think is the recommended way, they are then shared with every viewer, because the viewers are using the creator's UserProperties and not their own.






          share|improve this answer





















            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53204686%2fgoogle-data-studio-community-connector-how-to-share-credentials-to-3rd-party-e%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            1
            down vote













            I got inspired by Session.getEffectiveUser(), which is different depending on the user under whose authority the script is running.



            After some testing with a 2nd Google Account I shared a report with, I come to the conclusion that the UserProperties/UserCache behave differently, depending on the option that the report's creator has chosen on whose credentials access should be used. There is a guide about this here.



            Basically, if you choose "Owner's credentials access", which is the default, the UserProperties/UserCache of the creator are being shared with every other viewer. Whereas if you choose "Viewer's credentials access" the UserProperties/UserCache of the current viewer are used.



            This means that if you store the credentials in the creator's UserProperties, which I think is the recommended way, they are then shared with every viewer, because the viewers are using the creator's UserProperties and not their own.






            share|improve this answer

























              up vote
              1
              down vote













              I got inspired by Session.getEffectiveUser(), which is different depending on the user under whose authority the script is running.



              After some testing with a 2nd Google Account I shared a report with, I come to the conclusion that the UserProperties/UserCache behave differently, depending on the option that the report's creator has chosen on whose credentials access should be used. There is a guide about this here.



              Basically, if you choose "Owner's credentials access", which is the default, the UserProperties/UserCache of the creator are being shared with every other viewer. Whereas if you choose "Viewer's credentials access" the UserProperties/UserCache of the current viewer are used.



              This means that if you store the credentials in the creator's UserProperties, which I think is the recommended way, they are then shared with every viewer, because the viewers are using the creator's UserProperties and not their own.






              share|improve this answer























                up vote
                1
                down vote










                up vote
                1
                down vote









                I got inspired by Session.getEffectiveUser(), which is different depending on the user under whose authority the script is running.



                After some testing with a 2nd Google Account I shared a report with, I come to the conclusion that the UserProperties/UserCache behave differently, depending on the option that the report's creator has chosen on whose credentials access should be used. There is a guide about this here.



                Basically, if you choose "Owner's credentials access", which is the default, the UserProperties/UserCache of the creator are being shared with every other viewer. Whereas if you choose "Viewer's credentials access" the UserProperties/UserCache of the current viewer are used.



                This means that if you store the credentials in the creator's UserProperties, which I think is the recommended way, they are then shared with every viewer, because the viewers are using the creator's UserProperties and not their own.






                share|improve this answer












                I got inspired by Session.getEffectiveUser(), which is different depending on the user under whose authority the script is running.



                After some testing with a 2nd Google Account I shared a report with, I come to the conclusion that the UserProperties/UserCache behave differently, depending on the option that the report's creator has chosen on whose credentials access should be used. There is a guide about this here.



                Basically, if you choose "Owner's credentials access", which is the default, the UserProperties/UserCache of the creator are being shared with every other viewer. Whereas if you choose "Viewer's credentials access" the UserProperties/UserCache of the current viewer are used.



                This means that if you store the credentials in the creator's UserProperties, which I think is the recommended way, they are then shared with every viewer, because the viewers are using the creator's UserProperties and not their own.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 13 at 16:00









                Gregor Sondermeier

                415




                415






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53204686%2fgoogle-data-studio-community-connector-how-to-share-credentials-to-3rd-party-e%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    這個網誌中的熱門文章

                    Xamarin.form Move up view when keyboard appear

                    Post-Redirect-Get with Spring WebFlux and Thymeleaf

                    Anylogic : not able to use stopDelay()