4 ms·

View 1 comes from us (see my reply to your comment below). As for your 2nd question - that is the crux of the problem we had.

by inoda 8y ago

treis 8y ago
If View 1 comes from you why can't you give it back to the user on refresh?
- Bamafan 8y ago
  Even if they added this feature, the API bug would still remain (it would just be covered up by the UI). A sophisticated enough client user would still have access to the all data associated to the API user.
  - treis 8y ago
    >Even if they added this feature, the API bug would still remain (it would just be covered up by the UI). It's not really a bug though. It sounds like DS shows a dashboard for the user absent an instruction to show a different page. That's a reasonable default. >A sophisticated enough client user would still have access to the all data associated to the API user. If you use one account to access an API then of course it's your responsibility to control access. How would the API provider be able to do that?
    - Bamafan 8y ago
      I think the part that you may be missing is that View 1 (embedded view) is hosted on DocuSign's domain. So the view may be designed by the client, but it's not hosted by the client. It's hosted on DocuSign. Then View 2, is the "dashboard" view which of course isn't designed by the client. In an ideally designed embedded View 1, it should not be possible to get to DocuSign's "dashboard" (View 2). Sessions should be tracked in DocuSign's API and View 1 refreshes should return the user to hosted View 1 or should return an error.
      - treis 8y ago
        I thought OP was embedding something from DS in their page. It sounds like they are redirecting a user to DocuSign.com. I agree that the user being able to access the requester's DS is a massive security issue. So massive that it seems implausible that it actually works that way, but I don't have any experience to know one way or another.
- dahfizz 8y ago
  From my understanding, thier application redirects to a webpage that DocuSign owns (which ideally redirects back to the original website). Once the user is on some DocuSign.com webpage, you have no control at all over what happens. After you click on a search result and are served a webpage not owned by Google, Google can't control what happens if you press the refresh button.

View 1 comes from us (see my reply to your comment below). As for your 2nd question - that is the crux of the problem we had.

by inoda 8y ago

View 1 comes from us (see my reply to your comment below). As for your 2nd question - that is the crux of the problem we had.

treis 8y ago

If View 1 comes from you why can't you give it back to the user on refresh?

Bamafan 8y ago
Even if they added this feature, the API bug would still remain (it would just be covered up by the UI). A sophisticated enough client user would still have access to the all data associated to the API user.
- treis 8y ago
  >Even if they added this feature, the API bug would still remain (it would just be covered up by the UI). It's not really a bug though. It sounds like DS shows a dashboard for the user absent an instruction to show a different page. That's a reasonable default. >A sophisticated enough client user would still have access to the all data associated to the API user. If you use one account to access an API then of course it's your responsibility to control access. How would the API provider be able to do that?
  - Bamafan 8y ago
    I think the part that you may be missing is that View 1 (embedded view) is hosted on DocuSign's domain. So the view may be designed by the client, but it's not hosted by the client. It's hosted on DocuSign. Then View 2, is the "dashboard" view which of course isn't designed by the client. In an ideally designed embedded View 1, it should not be possible to get to DocuSign's "dashboard" (View 2). Sessions should be tracked in DocuSign's API and View 1 refreshes should return the user to hosted View 1 or should return an error.
    - treis 8y ago
      I thought OP was embedding something from DS in their page. It sounds like they are redirecting a user to DocuSign.com. I agree that the user being able to access the requester's DS is a massive security issue. So massive that it seems implausible that it actually works that way, but I don't have any experience to know one way or another.
dahfizz 8y ago
From my understanding, thier application redirects to a webpage that DocuSign owns (which ideally redirects back to the original website). Once the user is on some DocuSign.com webpage, you have no control at all over what happens. After you click on a search result and are served a webpage not owned by Google, Google can't control what happens if you press the refresh button.