Hi Ayoma, Thanks for the clarification.
The purpose of widget state is to contain non-sensitive information such as filter criteria of widgets (ex. date range to select data from a database). We do not recommend storing sensitive information such as access token in the hash since it will be visible over sharing the process (ex. sending the URL via chat, email, etc). Even though we do not recommend such use, it is up to the widget author to decide what to put in the URL hash. And also there can be scenario where the sharee doesn't have proper permission to display a widget. This can be 2 types such as, 1. Sharee have access to view the widget but no permission to access the data 2. Sharee doesn't have permission to even access the widget These scenario may cause problems since the user doesn't have permission to view the widget but some of the data is exposed via the URL hash. But if the widget author adheres to the rule of not putting sensitive information to the URL, I don't think these scenario won't be a problem anymore. WDYT? And also in the dashboard itself we refer widgets using UUIDs instead of fragment IDs, hence even in a situtation where the end user doesn't have permission to view even the gadget, again this won't be a problem as well. Appreciate your feedback on above as well. Thanks, *Lasantha Samarakoon* | Software Engineer WSO2, Inc. #20, Palm Grove, Colombo 03, Sri Lanka Mobile: +94 (71) 214 1576 Email: lasant...@wso2.com Web: www.wso2.com lean . enterprise . middleware On Fri, May 5, 2017 at 5:12 PM, Ayoma Wijethunga <ay...@wso2.com> wrote: > Hi Lasantha, > > Fragment ID of a Fragment URL (part after hash sign) will not be sent in > the HTTP Request back to the server. Also "Referer" header sent by browsers > should not include fragment ID [1]. Hence, data will not be logged in > intermediate proxies or any sort of server side access logs, and will not > be exposed to external application via Referer header. > > One concern is that the end user (and for example a shoulder surfer) will > be able to see the data part directly in the browser URL. It will open up a > security loophole if confidential information is sent in the fragment ID. > Such confidential information will include session identifiers, credentials > or tokens. > > If this does not concern confidential information, I do not think this > will open up a security loophole. > > It is best if you could further clarify if we are planning to pass any > confidential values in fragment ID. If so we might need to look at other > approaches. > > @Team: Any other thoughts? > > [1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 > > Best Regards, > Ayoma. > > > On Fri, May 5, 2017 at 4:45 PM, Lasantha Samarakoon <lasant...@wso2.com> > wrote: > >> [+Adding security team] >> >> @Security team: In the above first approach, we suppose to store widget >> state details in the URL hash as the given example. Can this be a security >> loophole since it exposes some of the data (ex. search criteria) used by >> the widgets via the URL? >> >> *Lasantha Samarakoon* | Software Engineer >> WSO2, Inc. >> #20, Palm Grove, Colombo 03, Sri Lanka >> Mobile: +94 (71) 214 1576 <+94%2071%20214%201576> >> Email: lasant...@wso2.com >> Web: www.wso2.com >> >> lean . enterprise . middleware >> >> On Fri, May 5, 2017 at 11:35 AM, Lasantha Samarakoon <lasant...@wso2.com> >> wrote: >> >>> [Dashboard] Sharing a dashboard >>> >>> Hi all, >>> >>> I am currently working on dashboard sharing feature in UUF dashboard >>> component which will allow a user to share a dashboard with current state >>> (i.e. selected field values, chart drill-downs, etc.). To implement this we >>> need to maintain the state of each widget somewhere and retrieve those on >>> dashboard restoring process. The same feature has been implemented in the >>> previous dashboard version and it worked as follows. >>> >>> In the dashboard 2.0.0 the gadget state is persisted in the URL hash. >>> The dashboard exposes a client side API[1] for gadgets to persist and >>> retrieve data in URL hash. >>> >>> *APIs:* >>> >>> wso2.gadgets.state.setGadgetState(state, callback); >>> >>> wso2.gadgets.state.getGadgetState(callback); >>> >>> wso2.gadgets.state.getGlobalState(callback); >>> >>> wso2.gadgets.state.setGlobalState(key, state, callback); >>> >>> Once the states are saved the URL will looks like; >>> >>> https://dashboard.example.com/portal/dashboard/my-dashboard# >>> /gadget-a/{data of gadget-a}/gadget-b/{data of gadget-b >>> >>> One of the main advantage of this approach is that a user can simply >>> copy the URL and share. If the permission has been granted others can view >>> the dashboard with exact state. >>> >>> In addition to the above approach there was another approach has come up >>> in our discussions to implement this feature, i.e. using the database as a >>> persistence medium for widget states. >>> >>> *Using database as persistence medium:* >>> >>> In this approach we need to introduce a new button to save the current >>> state of the dashboard in the database and provide a sharable link to >>> restore (somewhat similar to how the Google docs works). The sharable link >>> will looks like; >>> >>> https://dashboard.example.com/portal/shared/<KEY> >>> >>> The <KEY> in the above URL can be used to fetch the state with other >>> meta-info from the database and restore the dashboard. Drawbacks of this >>> approach are as follows. >>> >>> 1. User has to perform an extra action to get the sharable link. >>> 2. Database will persist data for each share, so sometimes purging >>> will be needed. >>> >>> Appreciate your comments on above to finalize the approach we are going >>> to use on UUF dashboard component. >>> >>> [1] https://github.com/wso2/carbon-dashboards/blob/2.0.x/com >>> ponents/shindig-wso2-features/src/main/javascript/wso2featur >>> es/state/state.js >>> >>> >>> Thanks, >>> >>> *Lasantha Samarakoon* | Software Engineer >>> WSO2, Inc. >>> #20, Palm Grove, Colombo 03, Sri Lanka >>> Mobile: +94 (71) 214 1576 <+94%2071%20214%201576> >>> Email: lasant...@wso2.com >>> Web: www.wso2.com >>> >>> lean . enterprise . middleware >>> >> >> > > > -- > Ayoma Wijethunga > Associate Technical Lead > Platform Security Team > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > Mobile : +94 (0) 719428123 <+94+(0)+719428123> > Blog : http://www.ayomaonline.com > LinkedIn: https://www.linkedin.com/in/ayoma >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
