Hi All, I think we need to have TTL (Time To Live/Expiry time) for each OTDL. Download link used after the expiry time should be denied. The generate OTDL API call can carry the TTL parameter optionally.
Cheers, Ruwan On Tue, Jun 7, 2016 at 10:42 AM, Chathura Dilan <[email protected]> wrote: > Hi Thilini, > > +1 for this approach > > > > Please see my comments inline > > > > 1. The generated download link is not secured since it is a one-time > download link. Is there a security concern regarding this approach? > > There is no major security issue in this approach. I'm adding Prabath for > more ideas > > > > 2. According to above, a single user will have to generate separate app > download links, in a case where he has several devices to download the app. > In that case, are we going to limit > > User should be able to generate multiple download links from one request. > But we can introduce a throttling mechanism for app installation requests > for security purpose. > > > > 3. Are we going to persist the details of the device (device id) that the > download link had been generated for so that we can enforce the security? > > It's good if we can persist the download request for analytics purposes. > IMO we don't need to persist other information like device ID. > > > > > > > > > > On Tue, Jun 7, 2016 at 9:31 AM, Lahiru Cooray <[email protected]> wrote: > >> >> >> On Tue, Jun 7, 2016 at 9:12 AM, Thilini Shanika <[email protected]> >> wrote: >> >>> Hi all, >>> >>> We are planning to implement one-time app download link support for >>> mobile application installation/download in App Manager 1.2.0. The main >>> objective of introducing this feature is to overcome security issues with >>> the current approach of installing mobile apps. >>> >>> Below is the designed approach of achieving $Subject. >>> >>> >>> According to above, >>> >>> - User login to App Store and make subscription/installation to a >>> particular mobile app >>> - One time download link is generated for the user >>> (/binaries/one-time/{UUID}) and the mapping of generated UUID and >>> the actual binary file is persisted in a Database table. The status of >>> the >>> download will be marked as 0 to indicate that the download link has not >>> been used yet. >>> - The device will access the binary download API via the generated >>> UUID to install the app. When the download/installation is completed, the >>> status of the binary downloadable URL reference will be marked as 1 to >>> indicate it has been used once. After an app download, any other access >>> to >>> the link will be prohibited. >>> >>> >>> There are few concerns regarding the implementation. >>> >>> - The generated download link is not secured since it is a one-time >>> download link. Is there a security concern regarding this approach? >>> - According to above, a single user will have to generate separate >>> app download links, in a case where he has several devices to download >>> the >>> app. In that case, are we going to limit (Configurable limit) the number >>> of >>> download links that can be generated by a single user? >>> >>> AFAIK we use the same operation to perform the enterprise installation >> as well, where an admin user can install an App to several users/devices. >> In that case I don't think limiting generation of download links user wise >> would be a good option (unless we consider the devices as well) >> >>> >>> - Are we going to persist the details of the device (device id) that >>> the download link had been generated for so that we can enforce the >>> security? >>> >>> +1 >> >>> Your comments and suggestions are highly appreciated. >>> >>> Thanks >>> Thilini >>> >>> >>> -- >>> Thilini Shanika >>> Senior Software Engineer >>> WSO2, Inc.; http://wso2.com >>> 20, Palmgrove Avenue, Colombo 3 >>> >>> E-mail: [email protected] >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Lahiru Cooray* >> Software Engineer >> WSO2, Inc.;http://wso2.com/ >> lean.enterprise.middleware >> >> Mobile: +94 715 654154 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Regards, > > Chatura Dilan Perera > *Associate Tech Lead** - WSO2 Inc.* > www.dilan.me > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Ruwan Abeykoon* *Associate Director/Architect**,* *WSO2, Inc. http://wso2.com <http://wso2.com/> * *lean.enterprise.middleware.* email: [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
