Re: svn commit: r521662 - in /maven/continuum/trunk: continuum-model/pom.xml pom.xml
Yes, with the actual version of Modello.
Without output directories, files are generated in wrong directories.
Emmanuel
Rahul Thakur a écrit :
Do we really need to specify the outputDirectory?
Eclipse barfs on output folders being added as source directories and
flags build errors (Eclipse related) on all dependent projects.
Rahul
On 3/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Fri Mar 23 03:31:35 2007
New Revision: 521662
URL: http://svn.apache.org/viewvc?view=revrev=521662
Log:
Use the released modello
Fix the build with the new modello
Modified:
maven/continuum/trunk/continuum-model/pom.xml
maven/continuum/trunk/pom.xml
Modified: maven/continuum/trunk/continuum-model/pom.xml
URL:
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-model/pom.xml?view=diffrev=521662r1=521661r2=521662
==
--- maven/continuum/trunk/continuum-model/pom.xml (original)
+++ maven/continuum/trunk/continuum-model/pom.xml Fri Mar 23 03:31:35
2007
@@ -46,6 +46,7 @@
/goals
configuration
modelsrc/main/mdo/continuum.xml/model
+
outputDirectory${basedir}/target/classes/META-INF/outputDirectory
/configuration
/execution
execution
@@ -55,6 +56,7 @@
/goals
configuration
modelsrc/main/mdo/continuum.xml/model
+
outputDirectory${basedir}/target/classes/META-INF/outputDirectory
replicationParameterstrue/replicationParameters
/configuration
/execution
Modified: maven/continuum/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/maven/continuum/trunk/pom.xml?view=diffrev=521662r1=521661r2=521662
==
--- maven/continuum/trunk/pom.xml (original)
+++ maven/continuum/trunk/pom.xml Fri Mar 23 03:31:35 2007
@@ -74,7 +74,7 @@
plugin
groupIdorg.codehaus.modello/groupId
artifactIdmodello-maven-plugin/artifactId
- version1.0-alpha-15-SNAPSHOT/version
+ version1.0-alpha-15/version
/plugin
/plugins
/pluginManagement
Re: XML RPC security
Maybe, but I can't find it.
Emmanuel
Rahul Thakur a écrit :
I thought there was something similar to this that exists in Redback?
Rahul
- Original Message - From: Emmanuel Venisse
[EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Saturday, April 28, 2007 12:37 AM
Subject: Re: XML RPC security
I think it's best solution. With a token, we don't have login/password
over the network for each request.
XmlRpcService
String login( username, password ) //return a token
{
tokenManager.login( username, password );
}
Object method1( token, params ) //null token for guest user or a
getGuestToken() method that will return it
{
User user = tokenManager.getUser( token );
...
}
Object method2( token, params )
{
...
}
TokenManager
String login( username, password ); //return a token
User getUser( token )
The TokenManager can be a plexus component with a default
implementation for redback.
wdyt?
Emmanuel
Emmanuel Venisse a écrit :
Hey guys,
Some quick notes on the security for XML RPC interface. This is what I
am thinking...
Have an AuthenticatedXmlRpcService component that services the xml rpc
requests. The first request from a client to the service is a request
for authentication. A successful authentication returns an
authentication Token, which is passed along with subsequent requests by
the client. A Token can go stale (configurable time period?) if there
were not requests detected for it. Also, we could have a service that
answers any polling requests and keeps a Token 'alive'.
Thoughts?
Rahul
Re: svn commit: r521662 - in /maven/continuum/trunk: continuum-model/pom.xml pom.xml
So we need to fix modello to output resources to correct directories,
right?
(I'd hate to swtich IDEs just for this ;-) )
Rahul
- Original Message -
From: Emmanuel Venisse [EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Monday, April 30, 2007 9:30 PM
Subject: Re: svn commit: r521662 - in /maven/continuum/trunk:
continuum-model/pom.xml pom.xml
Yes, with the actual version of Modello.
Without output directories, files are generated in wrong directories.
Emmanuel
Rahul Thakur a écrit :
Do we really need to specify the outputDirectory?
Eclipse barfs on output folders being added as source directories and
flags build errors (Eclipse related) on all dependent projects.
Rahul
On 3/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Fri Mar 23 03:31:35 2007
New Revision: 521662
URL: http://svn.apache.org/viewvc?view=revrev=521662
Log:
Use the released modello
Fix the build with the new modello
Modified:
maven/continuum/trunk/continuum-model/pom.xml
maven/continuum/trunk/pom.xml
Modified: maven/continuum/trunk/continuum-model/pom.xml
URL:
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-model/pom.xml?view=diffrev=521662r1=521661r2=521662
==
--- maven/continuum/trunk/continuum-model/pom.xml (original)
+++ maven/continuum/trunk/continuum-model/pom.xml Fri Mar 23
03:31:35 2007
@@ -46,6 +46,7 @@
/goals
configuration
modelsrc/main/mdo/continuum.xml/model
+
outputDirectory${basedir}/target/classes/META-INF/outputDirectory
/configuration
/execution
execution
@@ -55,6 +56,7 @@
/goals
configuration
modelsrc/main/mdo/continuum.xml/model
+
outputDirectory${basedir}/target/classes/META-INF/outputDirectory
replicationParameterstrue/replicationParameters
/configuration
/execution
Modified: maven/continuum/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/maven/continuum/trunk/pom.xml?view=diffrev=521662r1=521661r2=521662
==
--- maven/continuum/trunk/pom.xml (original)
+++ maven/continuum/trunk/pom.xml Fri Mar 23 03:31:35 2007
@@ -74,7 +74,7 @@
plugin
groupIdorg.codehaus.modello/groupId
artifactIdmodello-maven-plugin/artifactId
- version1.0-alpha-15-SNAPSHOT/version
+ version1.0-alpha-15/version
/plugin
/plugins
/pluginManagement
Re: svn commit: r521662 - in /maven/continuum/trunk: continuum-model/pom.xml pom.xml
Rahul Thakur a écrit :
So we need to fix modello to output resources to correct directories,
right?
Yes.
(I'd hate to swtich IDEs just for this ;-) )
Rahul
- Original Message - From: Emmanuel Venisse
[EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Monday, April 30, 2007 9:30 PM
Subject: Re: svn commit: r521662 - in /maven/continuum/trunk:
continuum-model/pom.xml pom.xml
Yes, with the actual version of Modello.
Without output directories, files are generated in wrong directories.
Emmanuel
Rahul Thakur a écrit :
Do we really need to specify the outputDirectory?
Eclipse barfs on output folders being added as source directories and
flags build errors (Eclipse related) on all dependent projects.
Rahul
On 3/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Fri Mar 23 03:31:35 2007
New Revision: 521662
URL: http://svn.apache.org/viewvc?view=revrev=521662
Log:
Use the released modello
Fix the build with the new modello
Modified:
maven/continuum/trunk/continuum-model/pom.xml
maven/continuum/trunk/pom.xml
Modified: maven/continuum/trunk/continuum-model/pom.xml
URL:
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-model/pom.xml?view=diffrev=521662r1=521661r2=521662
==
--- maven/continuum/trunk/continuum-model/pom.xml (original)
+++ maven/continuum/trunk/continuum-model/pom.xml Fri Mar 23
03:31:35 2007
@@ -46,6 +46,7 @@
/goals
configuration
modelsrc/main/mdo/continuum.xml/model
+ outputDirectory${basedir}/target/classes/META-INF/outputDirectory
/configuration
/execution
execution
@@ -55,6 +56,7 @@
/goals
configuration
modelsrc/main/mdo/continuum.xml/model
+ outputDirectory${basedir}/target/classes/META-INF/outputDirectory
replicationParameterstrue/replicationParameters
/configuration
/execution
Modified: maven/continuum/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/maven/continuum/trunk/pom.xml?view=diffrev=521662r1=521661r2=521662
==
--- maven/continuum/trunk/pom.xml (original)
+++ maven/continuum/trunk/pom.xml Fri Mar 23 03:31:35 2007
@@ -74,7 +74,7 @@
plugin
groupIdorg.codehaus.modello/groupId
artifactIdmodello-maven-plugin/artifactId
- version1.0-alpha-15-SNAPSHOT/version
+ version1.0-alpha-15/version
/plugin
/plugins
/pluginManagement
Re: XML RPC security
I don't think you need to handle the authentication part in the
continuum code, nor need to create tokens,...
If you use standard Digest authentication the password is encrypted,
and if you tie that with https then it's completely secure.
Acegi uses a filter to process all the requests and populate the auth
info or return the standard http codes if user not authenticated
http://www.acegisecurity.org/docbook/acegi.html#digest
On 4/30/07, Jesse McConnell [EMAIL PROTECTED] wrote:
I am hoping to get a couple of authn and authz web services running in
redback this week, once I finish up the role profile refactor and
clean up, I want to wack out a webservice and then start getting
continuum integrated to using the new redback setup.
sounds like that would work perfectly for this xml-rpc stuff in continuum.
rahul, planning on using xfire until the apache CXF stuff gets it
first release out of the incubator...that sound good?
jesse
On 4/30/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Maybe, but I can't find it.
Emmanuel
Rahul Thakur a écrit :
I thought there was something similar to this that exists in Redback?
Rahul
- Original Message - From: Emmanuel Venisse
[EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Saturday, April 28, 2007 12:37 AM
Subject: Re: XML RPC security
I think it's best solution. With a token, we don't have login/password
over the network for each request.
XmlRpcService
String login( username, password ) //return a token
{
tokenManager.login( username, password );
}
Object method1( token, params ) //null token for guest user or a
getGuestToken() method that will return it
{
User user = tokenManager.getUser( token );
...
}
Object method2( token, params )
{
...
}
TokenManager
String login( username, password ); //return a token
User getUser( token )
The TokenManager can be a plexus component with a default
implementation for redback.
wdyt?
Emmanuel
Emmanuel Venisse a écrit :
Hey guys,
Some quick notes on the security for XML RPC interface. This is what I
am thinking...
Have an AuthenticatedXmlRpcService component that services the xml rpc
requests. The first request from a client to the service is a request
for authentication. A successful authentication returns an
authentication Token, which is passed along with subsequent requests by
the client. A Token can go stale (configurable time period?) if there
were not requests detected for it. Also, we could have a service that
answers any polling requests and keeps a Token 'alive'.
Thoughts?
Rahul
--
jesse mcconnell
[EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: XML RPC security
I have never really messed with authenticated web services at all so
not sure what to say..
I'll take a look through that though, thanks carlos
jesse
On 4/30/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
I don't think you need to handle the authentication part in the
continuum code, nor need to create tokens,...
If you use standard Digest authentication the password is encrypted,
and if you tie that with https then it's completely secure.
Acegi uses a filter to process all the requests and populate the auth
info or return the standard http codes if user not authenticated
http://www.acegisecurity.org/docbook/acegi.html#digest
On 4/30/07, Jesse McConnell [EMAIL PROTECTED] wrote:
I am hoping to get a couple of authn and authz web services running in
redback this week, once I finish up the role profile refactor and
clean up, I want to wack out a webservice and then start getting
continuum integrated to using the new redback setup.
sounds like that would work perfectly for this xml-rpc stuff in continuum.
rahul, planning on using xfire until the apache CXF stuff gets it
first release out of the incubator...that sound good?
jesse
On 4/30/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Maybe, but I can't find it.
Emmanuel
Rahul Thakur a écrit :
I thought there was something similar to this that exists in Redback?
Rahul
- Original Message - From: Emmanuel Venisse
[EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Saturday, April 28, 2007 12:37 AM
Subject: Re: XML RPC security
I think it's best solution. With a token, we don't have login/password
over the network for each request.
XmlRpcService
String login( username, password ) //return a token
{
tokenManager.login( username, password );
}
Object method1( token, params ) //null token for guest user or a
getGuestToken() method that will return it
{
User user = tokenManager.getUser( token );
...
}
Object method2( token, params )
{
...
}
TokenManager
String login( username, password ); //return a token
User getUser( token )
The TokenManager can be a plexus component with a default
implementation for redback.
wdyt?
Emmanuel
Emmanuel Venisse a écrit :
Hey guys,
Some quick notes on the security for XML RPC interface. This is what I
am thinking...
Have an AuthenticatedXmlRpcService component that services the xml rpc
requests. The first request from a client to the service is a request
for authentication. A successful authentication returns an
authentication Token, which is passed along with subsequent requests by
the client. A Token can go stale (configurable time period?) if there
were not requests detected for it. Also, we could have a service that
answers any polling requests and keeps a Token 'alive'.
Thoughts?
Rahul
--
jesse mcconnell
[EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
--
jesse mcconnell
[EMAIL PROTECTED]
