4 ms·

>1. Go to an embedded page, authenticated as the “API user” (which looks like you’re sandboxed within DS to the embedded page) >2. Refresh the page >3. You no

by treis 8y ago

>1. Go to an embedded page, authenticated as the “API user” (which looks like you’re sandboxed within DS to the embedded page) >2. Refresh the page >3. You now can click around the entire account - viewing any data that belongs to the API user (in our case, all of the data). I don't quite understand this. Shouldn't you be able to control what is displayed during the refresh?

inoda 8y ago
No, their embedded view is hosted on their site. The functionality is directing to them to a page on their site, with a redirect URL to our app after they are "done" there. This allows DS to be embedded into app-side workflows.
- treis 8y ago
  >No, their embedded view is hosted on their site. Right, but aren't you telling them which view to show? For example, show document X for the user to sign.
  - inoda 8y ago
    Yes. The problem is that on page refresh, that constraint is lost and the user is logged into the account, in DS UI. They can click around anywhere at this point, outside of the page we specified.
    - Bamafan 8y ago
      I'm curious as to how HelloSign guards against this. Do they have some sort of session token that sends you back to the signing page on refresh? (i.e. similar to guard to avoid submitting shopping cart purchases twice).
      - deleted 8y ago
        [deleted]
      - inoda 8y ago
        HelloSign's embedded signing happens in a iframe, through their JS client. The user is never directed to HelloSign's site unless you choose to to an un-embedded workflow.
    - treis 8y ago
      >The problem is that on page refresh, that constraint is lost Why can't you put this constraint in a session and pass it back in on refresh?
      - inoda 8y ago
        View 1 is on the DS domain. We have no control once the user is in there aside from giving the redirect URL.
        treis 8y ago
        This is the point where someone is extremely confused but I'm not sure which one of us it is. My understanding is that you have a page at the end of some process for the user to sign a document. The first time the user goes to the page they see the screen to sign something (View 1). They refresh the screen. Now they see some dashboard like screen where they can see everything (View 2). Is that not right?
        inoda 8y ago
        1. We want the application user to sign a contract. 2. We request an embedded signing url from DS (we provide authentication creds, as well as redirect url as params - what we get back is a "special" url on DS. E.g. it is docusign.com/blahblahblah) 3. We redirect the user to the special DS url. 4. If the user signs, or refuses to sign or w/e, the user will get redirected back to our application via the redirect url we provided in our request on step #2. If the user instead decides to refresh the page, they for some reason are broken out of the signing page, and can now do whatever they want in the account as they are logged into DS's site for some reason.
        treis 8y ago
        So you're not embedding the DS page in your site. You're redirecting the user to DS?
- deleted 8y ago
  [deleted]
stronglikedan 8y ago
I understood it as they were using the API for validation but loading the embedded content straight from DS, in which case they wouldn't be able to control whatever's displayed in the embed.
- treis 8y ago
  A user goes to a page and sees DocuSign view 1. Now they refresh and see DocuSign view 2 that shows everything. How did they get they get view 1 and why couldn't they do it again on refresh?
  - 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?

by treis 8y ago

inoda 8y ago

No, their embedded view is hosted on their site. The functionality is directing to them to a page on their site, with a redirect URL to our app after they are "done" there. This allows DS to be embedded into app-side workflows.

treis 8y ago
>No, their embedded view is hosted on their site. Right, but aren't you telling them which view to show? For example, show document X for the user to sign.
- inoda 8y ago
  Yes. The problem is that on page refresh, that constraint is lost and the user is logged into the account, in DS UI. They can click around anywhere at this point, outside of the page we specified.
  - Bamafan 8y ago
    I'm curious as to how HelloSign guards against this. Do they have some sort of session token that sends you back to the signing page on refresh? (i.e. similar to guard to avoid submitting shopping cart purchases twice).
    - deleted 8y ago
      [deleted]
    - inoda 8y ago
      HelloSign's embedded signing happens in a iframe, through their JS client. The user is never directed to HelloSign's site unless you choose to to an un-embedded workflow.
  - treis 8y ago
    >The problem is that on page refresh, that constraint is lost Why can't you put this constraint in a session and pass it back in on refresh?
    - inoda 8y ago
      View 1 is on the DS domain. We have no control once the user is in there aside from giving the redirect URL.
      - treis 8y ago
        This is the point where someone is extremely confused but I'm not sure which one of us it is. My understanding is that you have a page at the end of some process for the user to sign a document. The first time the user goes to the page they see the screen to sign something (View 1). They refresh the screen. Now they see some dashboard like screen where they can see everything (View 2). Is that not right?
        inoda 8y ago
        1. We want the application user to sign a contract. 2. We request an embedded signing url from DS (we provide authentication creds, as well as redirect url as params - what we get back is a "special" url on DS. E.g. it is docusign.com/blahblahblah) 3. We redirect the user to the special DS url. 4. If the user signs, or refuses to sign or w/e, the user will get redirected back to our application via the redirect url we provided in our request on step #2. If the user instead decides to refresh the page, they for some reason are broken out of the signing page, and can now do whatever they want in the account as they are logged into DS's site for some reason.
        treis 8y ago
        So you're not embedding the DS page in your site. You're redirecting the user to DS?
deleted 8y ago
[deleted]

stronglikedan 8y ago

I understood it as they were using the API for validation but loading the embedded content straight from DS, in which case they wouldn't be able to control whatever's displayed in the embed.

treis 8y ago
A user goes to a page and sees DocuSign view 1. Now they refresh and see DocuSign view 2 that shows everything. How did they get they get view 1 and why couldn't they do it again on refresh?
- 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?