On Thu, Jun 16, 2016 at 7:50 AM, Thilini Shanika <[email protected]> wrote:
> Hi Chathura, > > Yes, that particular configuration is there for one-time download link > generation. > > > On Thu, Jun 16, 2016 at 5:00 PM, Chathura Dilan <[email protected]> > wrote: > >> Hi Thilini, >> >> For one time download URLs there should be a configuration to force https >> URLs or provide any host name + port as the host. Earlier it was >> <AppDownloadURLHost> [1] configuration . Is it currently possible with one >> time download URLs? >> >> [1] - >> https://docs.wso2.com/display/APPM100/Integrating+a+Mobile+Device+Manager >> >> >> >> On Tue, Jun 7, 2016 at 5:26 PM, Ruwan Abeykoon <[email protected]> wrote: >> >>> 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 >>>> >>> IMO - one-time download mechanism has to plugin to the details of each operative system. For example - iOS has a special mechanism in which the download happens (via a plist file). The device might call the back-end several times if things download fails. Best approach for iOS would be to give time-to-live urls (like an hour) rather than one-time. > >>>> >>>> 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. >>>> >>> +1. We could a CEP base throttling to be intuitive. > >>>> >>>> 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. >>>> >>> Persist it based on user - not to the device. I believe the device bit should be done if MDM is involved. > >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 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 >>> >>> >> >> >> -- >> 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 >> >> > > > -- > 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 > > -- Dulitha Wijewantha (Chan) Software Engineer - Mobile Development WSO2 Inc Lean.Enterprise.Middleware * ~Email [email protected] <[email protected]>* * ~Mobile +94712112165* * ~Website dulitha.me <http://dulitha.me>* * ~Twitter @dulitharw <https://twitter.com/dulitharw>* *~Github @dulichan <https://github.com/dulichan>* *~SO @chan <http://stackoverflow.com/users/813471/chan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
