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











up vote
0
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?






google-apps-script google-data-studio







share|improve this question




























    up vote
    0
    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?






    google-apps-script google-data-studio







    share|improve this question


























      up vote
      0
      down vote

      favorite









      up vote
      0
      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?






      google-apps-script google-data-studio







      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




      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

      114




      114





























          active

          oldest

          votes











          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























          active

          oldest

          votes













          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes
















           

          draft saved


          draft discarded



















































           


          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






































































          -

          Popular posts from this blog

          Guess what letter conforming each word

          Image
          6 $begingroup$ This is an entry in the Fortnightly Topic Challenge #41: Short and Sweet. 1 letter only could be mean anything . With an additional letter in front , could be used as medicine component and something you definitely learn or at least heard once. Add another letter in front , you would possibly hear that many times . Add an additional letter in front , you would found an independent country . With an additional letter, in the end , you would found something related to apple . Add another letter in the end , you would found something bad . Hint: Each letter is unique . word knowledge letters chemistry share | improve this question ...
          Read more

          Port of Spain

          Image
          For ports in the country of Spain, see List of ports in Spain. City in City of Port of Spain, Trinidad and Tobago Port of Spain City City of Port of Spain Top to bottom (left to right): Skyline of Port of Spain from Gulf of Paria; National Academy for the Performing Arts, Independence Square, Eric Williams Plaza; MovieTowne, Port of Port of Spain Motto(s):  "We Gather Strength As We Go Along" Port of Spain Coordinates: 10°40′N 61°31′W  /  10.667°N 61.517°W  / 10.667; -61.517 Coordinates: 10°40′N 61°31′W  /  10.667°N 61.517°W  / 10.667; -61.517 Country   Trinidad and Tobago Jurisdiction City of Port of Spain Settled 1560 Incorporated (town) 1853 Incorporated (city) 1914 Government  • Mayor Joel Martinez  • Governing body City Corporation Area [1]  • City 12 km 2 (5 sq mi) Elevation [2] 66 m (217 ft) Population (2011) [1]  • City 37,074  • Rank 3rd  • Density 3,090/km 2 (8,000/sq mi)...
          Read more

          Run scheduled task as local user group (not BUILTIN)

          Image
          0 I am trying to run a scheduled task with User Group (not a single user). This is working fine when I in the field "when running a task, use the following user account:" insert BUILTIN User Group (for example: Administrators or Users). But when I try it with the created Local User Group (example: TestGroup) it is not working. The Users in the TestGroup are the same as in the Administrators group. What could be the problem? Are there some restrictions to the Created User Group compared to BUILTINUsers? scheduled-tasks taskscheduler windowstaskschedule share | improve this question asked Nov 15 '18 at 15:36 Far...
          Read more