It was a design decision to not base p2 repository on a schema of the repository; it is considered an implementation detail of a particular type of repository.
If you are looking for a schema; there is one in the b3 aggregator which supports loading p2 repositories into an EMF model, do operations on the model etc., and then write it out again as a p2 repository. I have used that model for various p2 repo related things (can't share them though), but it was quite easy to use as it provides a standard EMF model API to the repository data. Don't know if that helps you in any way. Regards - henrik Henrik Lindberg [email protected] On Jan 3, 2013, at 6:07, Ervin O wrote: > Sorry for the late answer. > > This is exactly what I want to do. > > I just want to display custom set of modules(~IUs for simplicity) for the > clients based on their access rights. I also need an administration interface > where the module developers can publish their modules(module metadata), and > the administrators can manage the user's priviliges. The priviliges, users, > and metadata for the modules will be stored in a database and I will > dinamically generate custom content.xmls for the clients from the database. > When the provisioning is initiated, the client downloads this tailored > content.xml, and the invokes the IMetaDataRepositoryManager#loadRepository on > the local copy. Currenty I am working on this content.xml generator. The > problem is that I think it is not a standardized format for the metadata, but > I hope that it won't change in the near future. (I didn't find any schema > definition in the content.xml generated by Eclipse) It would be a great > improvement in the future to standardize the format of a P2 repository. :) > > If you have a better idea then don't hesitate to share it with me. > > Thank you, > > Ervin > > 2012/12/18 Pascal Rapicault <[email protected]> > When you have something working, it would be great if you could share some of > the details of what you’ve done as I’m sure you are not the first one to > solve this. > > > > Thx > > > > Pascal > > > > From: [email protected] [mailto:[email protected]] On > Behalf Of Ervin O > Sent: December-17-12 12:31 AM > To: P2 developer discussions > Subject: Re: [p2-dev] P2 security management > > > > Thank you for your answer, your idea helped me out. > > > > Yes, I will only use Equinox and P2 to achieve my goal. > > > > The "downloading the metadata and then invoking P2 on the local copy" is a > very good approach. I think, it will solve all of my problems. > > > > I will generate custom xml metadata for the users(visibility problem solved), > and I will embed a security key into the URL of the artifacts in addition. > Then I will check this key on the server, when the client downloads the > artifact. > > > > It is not problem for example if the user acquires the module in an illlegal > way and installs it because these modules are unusable without the server, so > hiding the modules is also enough. (Every module of the application is a > general purpose thin client.) > > > > Best, > > > > Ervin > > > > 2012/12/17 Henrik Lindberg <[email protected]> > > Since you say that you are creating an OSGi application I assume this is not > for the Eclipse IDE, and that you are planning to use just p2 APi to achieve > > what you want. If that is the case, then you can probably just add properties > to the IUs in question and then filter those out based on your logic that > discriminates on "user x has no right to see y". > > > > If you plan to do this with the regular Eclipse p2 UI, then it becomes a > matter of configuring the UI - i.e. what it displays in the UI. There are > many things that > > can be configured, but I am not sure if this is one of them (don't think I > heard about this anyway, but I could be wrong). > > > > In any case, this would be a very simple mechanism, clearly the metadata must > be accessible by the user, and it needs to be downloaded to the users machine > to be operated on - so the user will have this on the local disk and can thus > find information and invoke p2 manually to install things (using say the > director application, or just snooping, reading the XML text to figure things > out). What you can achieve easily is simply a "hide it from the user in the > UI". Is that enough? > > > > If you want to have real security/license enforcement you would need to do a > lot more. License enforcement is best done at runtime rather than install > time IMO, but since you want to hide things from users (the mere existence of > something installable is an issue), and you may to really keep the > information away from the local disk (preventing expert users from figuring > things out). If so, then you must either divide things up in different > repositories and only giving users the URLs/passwords to those repositories > they are allowed to see the content in (password protected, etc). You could > also implement your own Repository implementation to do something smarter > than downloading all of the metadata, and limit it to what the user is > allowed to see. > > > > If you have control over the backend repository implementation, you can do > things with the URLs/user login, and present the repository layout/content > dynamically. > > It does not prevent users from using system level tools to mirror things - > thus someone may leak sensitive repository content (i.e. mirror/copy things > to another repository from which they / or anyone else can install). > > > > Also, once something is installed; it is in re-installable form - someone > that can access what is installed can install from this location. > > > > Just a couple of ideas (and security concerns to think about) from the top of > my mind ... maybe others have better ideas (maybe there are already > implementations that does this...) - Yoxos perhaps? > > > > If "hiding it in the UI" is enough; the easiest is to do a server backend. If > you do this, and you want to write the p2 repository massaging in Java (as > opposed to dealing with the XML), you can use the b3 aggregators model of p2 > to conveniently load p2 repositories from your (secure) locations, perform > the filtering etc. and then output the result as a response to a HTTP > request. There are many other options available, but that is what I would do > (I have written other p2 repository processing logic that way - unfortunately > not available in open source). > > > > Hope that helps. > > > > Regards > > - henrik > > > > Henrik Lindberg > > [email protected] > > > > > > > > On Dec 17, 2012, at 4:56, Ervin O wrote: > > > > Hi, > > > > I am creating a modular application based on OSGi and I would like to use > P2 for provisioning. > > > > My application will have users who can install modules(deployed as IUs for > simplicity) with P2 and I want to restritct the visibility of the modules for > the users who have no privilege to install them. > > > > For example, if user U1 has no privilege to install the module M1, then he > wouldn't see it in the "available modules" list(retreived from the metadata > repository by P2) and can't download it even if he acquired the URL of the IU > and the location of the bundle in the artifact repository. > > > > Is there any way to do this or I have to do it manually? > > > > In the latter case, my main problem is that I don't know how to tell to P2 to > attach the user's session id to the http request (without building a custom > P2 that supports this feature). > > > > Thanks in advance! > > > > Cheers, > > > > Ervin > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > > > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > > > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
