[JBoss JIRA] (SRAMP-508) Restrict s-ramp artifacts depends on the environment
by David virgil naranjo (JIRA)
David virgil naranjo created SRAMP-508:
------------------------------------------
Summary: Restrict s-ramp artifacts depends on the environment
Key: SRAMP-508
URL: https://issues.jboss.org/browse/SRAMP-508
Project: S-RAMP
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: David virgil naranjo
Assignee: David virgil naranjo
The main idea proposed by Gary is to avoid snapshots artifacts in production.
The solution proposed by Eric is to recognize if the s-ramp artifact deployed contains the SNAPSHOT keyword. Then:
In case it contains SNAPSHOT: allow Snapshots and Released artifacts.
Not contains SNAPSHOT: allow just Released artifacts.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (SRAMP-507) Modify way the snapshot artifacts are stored in s-ramp
by David virgil naranjo (JIRA)
David virgil naranjo created SRAMP-507:
------------------------------------------
Summary: Modify way the snapshot artifacts are stored in s-ramp
Key: SRAMP-507
URL: https://issues.jboss.org/browse/SRAMP-507
Project: S-RAMP
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: David virgil naranjo
Assignee: David virgil naranjo
Fix For: 0.5.0
Include a property mvn.snapshot.timestamp (in case the name contains the timestamp)
Create a new artifact every time a different timestamp of the same artifact is uploaded. It would be exactly as maven is doing. Right now we update the content of the artifact instead of creating a new one.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (SRAMP-506) Maven repository facade. Add extended type
by Marc Savy (JIRA)
[ https://issues.jboss.org/browse/SRAMP-506?page=com.atlassian.jira.plugin.... ]
Marc Savy commented on SRAMP-506:
---------------------------------
Having spent ages having to meddle with this metadata on a previous project - I should mention that it can be extremely tricky to get the results you would expect (unless maven metadata is available).
For instance, in my experience the following aren't uncommon in externally provided JARs:
- `META-INF` directory to be missing entirely (essentially not a valid JAR)
- Manifest data often doesn't correspond with what you would expect, because the user decided can some arbitrary value in there (e.g. Bundle-Version => 2.1.0.201209190230-r instead of 2.1.0, presumably someone decided it'd be nice to have date and time in there). [1]
- There may be correct data available, but it might not be stored in the key you'd expect (sometimes people put them in Bundle-Version other times in Specification-Version)
- If there is a 'meta jar' (i.e. Jar wrapping a whole load of other Jars), it may not even have a `properties.pom`/maven metadata which is useful.
Ultimately for the worst cases I ended up having to use a heuristic based approach, with regexp for the ultimate fallback if all other methods failed (would we just reject completely malformed ones?).
While I was developing the aforementioned tooling, I wrote a little program which will scan through a directory tree, cracks open all of the jars and builds a set of keys (and values) from all the manifest files. This gives you a very good idea of which fields you may want to look at to derive the data you need, in addition to the sort of rubbish data it may contain you'll have to try to avoid!
Sample output (huge set): https://gist.github.com/msavy/cefc9c9b01416176128f
Note format is: key => { v0, v1, ..., Vn }
I'll post a source link as a priv comment as I haven't put any copyright headers and whatnot on it.
> Maven repository facade. Add extended type
> ------------------------------------------
>
> Key: SRAMP-506
> URL: https://issues.jboss.org/browse/SRAMP-506
> Project: S-RAMP
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: David virgil naranjo
> Assignee: David virgil naranjo
>
> It is necessary to add the possibility of setting a different s-ramp type.
> By default right now the s-ramp type is Java Archive. For uploading switchyard applications it is necessary to add a mechanism to set the extended type.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (SRAMP-380) Passwords in clear text when running in Fuse 6.1
by David virgil naranjo (JIRA)
[ https://issues.jboss.org/browse/SRAMP-380?page=com.atlassian.jira.plugin.... ]
David virgil naranjo commented on SRAMP-380:
--------------------------------------------
I did not find information in google about this, so i wrote a post in the fuse forum:
https://community.jboss.org/message/881181
> Passwords in clear text when running in Fuse 6.1
> ------------------------------------------------
>
> Key: SRAMP-380
> URL: https://issues.jboss.org/browse/SRAMP-380
> Project: S-RAMP
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Eric Wittmann
> Assignee: David virgil naranjo
> Fix For: 0.6.0
>
>
> When we install into JBoss EAP we make sure that we don't have any clear text passwords in any configuration files. This is made possible by using the Vault, which allows us to store passwords in the vault and then refer to those vault locations from our config files.
> I don't know if there is something similar to be done in Fuse 6.1
> In addition, the login credentials for supported users in EAP are not stored in clear text (the EAP Application Realm config files store an encrypted version of the passwords).
> In Fuse 6.1 we are storing the login user credentials in a users.properties file in clear text.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (SRAMP-506) Maven repository facade. Add extended type
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-506?page=com.atlassian.jira.plugin.... ]
Eric Wittmann edited comment on SRAMP-506 at 7/14/14 8:24 AM:
--------------------------------------------------------------
Couple thoughts on this. The first is that I don't think the classifier approach will work, because the main point of this feature is to set the S-RAMP ArtifactType for the *primary* artifact produced by a maven build. Setting a maven classifier changes the maven semantics, which is not what we want.
I also don't think a custom deploy plugin is the way to go, since the value of this feature is to avoid having to configure a custom plugin in the pom.xml. We already have a custom deploy plugin that can be used today! :) This maven facade is supposed to allow deployments without such a custom plugin.
The solution I think needs to come from the content of the artifact being deployed, as [~msavy] suggested. I think the best thing would be for us to look for a property set in one of the following three places:
* META-INF/maven/groupId/artifactId/pom.xml
* META-INF/MANIFEST.MF
* META-INF/maven/groupId/artifactId/pom.properties
I have listed them in the order I think makes sense. We should consider what's easiest for the end user. I think the easiest is to allow them to set a property in their pom.xml which we will consume. Alternatively we could check the manifest or the pom.properties. I think the pom.xml is the best because it's the easiest for the end user to configure - they simply add a property to their pom.xml. No further configuration necessary.
The downside to this approach is that the maven facade will need to save a full copy of the inbound artifact content locally so it can be cracked open and interrogated. It will also need to know what kind of artifact it is - because this approach will only work for primary artifacts that are some form of Zip file (which is most of them).
was (Author: eric.wittmann):
Couple thoughts on this. The first is that I don't think the classifier approach will work, because the main point of this feature is to set the S-RAMP ArtifactType for the *primary* artifact produced by a maven build. Setting a maven classifier changes the maven semantics, which is not what we want.
I also don't think a custom deploy plugin is the way to go, since the value of this feature is to avoid having to configure a custom plugin in the pom.xml. We already have a custom deploy plugin that can be used today! :) This maven facade is supposed to allow deployments without such a custom plugin.
The solution I think needs to come from the content of the artifact being deployed, as [~msavy] suggested. I think the best thing would be for us to look for a property set in one of the following three places:
* META-INF/maven/${groupId}/${artifactId}/pom.xml
* META-INF/MANIFEST.MF
* META-INF/maven/${groupId}/${artifactId}/pom.properties
I have listed them in the order I think makes sense. We should consider what's easiest for the end user. I think the easiest is to allow them to set a property in their pom.xml which we will consume. Alternatively we could check the manifest or the pom.properties. I think the pom.xml is the best because it's the easiest for the end user to configure - they simply add a property to their pom.xml. No further configuration necessary.
The downside to this approach is that the maven facade will need to save a full copy of the inbound artifact content locally so it can be cracked open and interrogated. It will also need to know what kind of artifact it is - because this approach will only work for primary artifacts that are some form of Zip file (which is most of them).
> Maven repository facade. Add extended type
> ------------------------------------------
>
> Key: SRAMP-506
> URL: https://issues.jboss.org/browse/SRAMP-506
> Project: S-RAMP
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: David virgil naranjo
> Assignee: David virgil naranjo
>
> It is necessary to add the possibility of setting a different s-ramp type.
> By default right now the s-ramp type is Java Archive. For uploading switchyard applications it is necessary to add a mechanism to set the extended type.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (SRAMP-506) Maven repository facade. Add extended type
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-506?page=com.atlassian.jira.plugin.... ]
Eric Wittmann commented on SRAMP-506:
-------------------------------------
Couple thoughts on this. The first is that I don't think the classifier approach will work, because the main point of this feature is to set the S-RAMP ArtifactType for the *primary* artifact produced by a maven build. Setting a maven classifier changes the maven semantics, which is not what we want.
I also don't think a custom deploy plugin is the way to go, since the value of this feature is to avoid having to configure a custom plugin in the pom.xml. We already have a custom deploy plugin that can be used today! :) This maven facade is supposed to allow deployments without such a custom plugin.
The solution I think needs to come from the content of the artifact being deployed, as [~msavy] suggested. I think the best thing would be for us to look for a property set in one of the following three places:
* META-INF/maven/${groupId}/${artifactId}/pom.xml
* META-INF/MANIFEST.MF
* META-INF/maven/${groupId}/${artifactId}/pom.properties
I have listed them in the order I think makes sense. We should consider what's easiest for the end user. I think the easiest is to allow them to set a property in their pom.xml which we will consume. Alternatively we could check the manifest or the pom.properties. I think the pom.xml is the best because it's the easiest for the end user to configure - they simply add a property to their pom.xml. No further configuration necessary.
The downside to this approach is that the maven facade will need to save a full copy of the inbound artifact content locally so it can be cracked open and interrogated. It will also need to know what kind of artifact it is - because this approach will only work for primary artifacts that are some form of Zip file (which is most of them).
> Maven repository facade. Add extended type
> ------------------------------------------
>
> Key: SRAMP-506
> URL: https://issues.jboss.org/browse/SRAMP-506
> Project: S-RAMP
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: David virgil naranjo
> Assignee: David virgil naranjo
>
> It is necessary to add the possibility of setting a different s-ramp type.
> By default right now the s-ramp type is Java Archive. For uploading switchyard applications it is necessary to add a mechanism to set the extended type.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (SRAMP-506) Maven repository facade. Add extended type
by David virgil naranjo (JIRA)
[ https://issues.jboss.org/browse/SRAMP-506?page=com.atlassian.jira.plugin.... ]
David virgil naranjo commented on SRAMP-506:
--------------------------------------------
The extended type has to be included for example for uploading switchyard applications. In that case, it is needed an extra param to specify the extended type.
I have been checking the maven deploy:deploy-file plugin:
http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html
The easier solution is to add a classifier, and in the server side check if the classifier correspond to a extended type used by us, or check if the classifier is different than the common maven classifiers, test, sources...
In case it is different than test or sources ( I do not know if by default they are more), then we could set the extended type.
This is the easy solution.. But maybe it could be confusing, because maybe sometimes we want to add a classifier, that is not really an extended type.
Another solution could be (thanks to Mark Savy), it is to include the artifact type in the META-INF MANIFEST file. Then the user should add this info to the jar, before deploying.
Another option maybe could be to create our custom deploy plugin, that extends from the official one, and extends the functionality to add a param in the urls like artifactType. Here the only problem is that the user, when he wants to include an extended artifact type has to disable the official maven deploy plugin (skip) and include the s-ramp one.
> Maven repository facade. Add extended type
> ------------------------------------------
>
> Key: SRAMP-506
> URL: https://issues.jboss.org/browse/SRAMP-506
> Project: S-RAMP
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: David virgil naranjo
> Assignee: David virgil naranjo
>
> It is necessary to add the possibility of setting a different s-ramp type.
> By default right now the s-ramp type is Java Archive. For uploading switchyard applications it is necessary to add a mechanism to set the extended type.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (SRAMP-505) maven:deploy CLI command missing maven.type property sometimes
by David virgil naranjo (JIRA)
[ https://issues.jboss.org/browse/SRAMP-505?page=com.atlassian.jira.plugin.... ]
David virgil naranjo updated SRAMP-505:
---------------------------------------
Git Pull Request: https://github.com/Governance/s-ramp/pull/453
> maven:deploy CLI command missing maven.type property sometimes
> --------------------------------------------------------------
>
> Key: SRAMP-505
> URL: https://issues.jboss.org/browse/SRAMP-505
> Project: S-RAMP
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Shell
> Reporter: Eric Wittmann
> Assignee: David virgil naranjo
> Fix For: 0.5.0
>
>
> The maven:deploy s-ramp cli command does not currently set the maven.type property under all circumstances. A requirement is that maven.type always be set. Currently the CLI command gets this information from the arguments to the command. In some cases the user will not include the "type" information on the command line. In this case the type should be pulled from the file extension of the file being uploaded.
> If the file being uploaded does *not* have an extension and the maven.type is not provided as part of the GAV argument, then the command should fail.
> Note: the name of the artifact should also include the file's extension - this is currently being left off.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (SRAMP-445) SSO not working on Tomcat
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-445?page=com.atlassian.jira.plugin.... ]
Eric Wittmann updated SRAMP-445:
--------------------------------
Fix Version/s: 0.6.0
(was: 0.5.0)
> SSO not working on Tomcat
> -------------------------
>
> Key: SRAMP-445
> URL: https://issues.jboss.org/browse/SRAMP-445
> Project: S-RAMP
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Eric Wittmann
> Assignee: Eric Wittmann
> Fix For: 0.6.0
>
>
> The IDP isn't quite working as an SSO provider when running in Tomcat. The SP properly redirects to the IDP but the IDP is requiring the user to authenticate again, even though they already have. To reproduce:
> 1) run both s-ramp and dtgov on tomcat
> 2) open browser, navigate to s-ramp-ui
> 3) log in
> 4) click on Design Time Governance
> At this point you will have to authenticate again. This is wrong.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months