Re: Guarding all Resources using one Guard
Thanks..I figured that out after posting the message :-)
Re: Restlet + OpenID
Do you think the new "Spring Security 2.0" could be helpful ? -> http://static.springframework.org/spring-security/site/ " [...] - OpenID integration, which is the web's emerging single sign on standard (supported by Google, IBM, Sun, Yahoo and others) [...] - Comprehensive support for RESTful web request authorization, which works well with Spring 2.5's @MVC model for building RESTful systems [...] " Jerome Louvel a écrit : Salut Jean-Yves, Thanks for the links. I've updated our RFE with them: http://restlet.tigris.org/issues/show_bug.cgi?id=229 Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Jean-Yves Cronier Envoyé : samedi 12 janvier 2008 01:18 À : discuss@restlet.tigris.org Objet : Re: Restlet + OpenID Some docs to begin: * http://wiki.openid.net/OpenID_HTTP_Authentication * http://wiki.openid.net/HTTP_Authentication * http://wiki.openid.net/OpenID_Exchange_1.0 Stian Soiland a écrit : On 1/3/08, Rob Heittman <[EMAIL PROTECTED]> wrote: While in concept, it is neat that OpenID providers could authenticate you by certificates, biometrics, facial recognition, or smell, in practice they generally employ userid and password pairs and therefore offer nothing stopping one from mapping that to HTTP Basic on a resource whose URI is advertised. Yeah, there's also nothing stopping an OpenID provider to be have a RESTful authentication scheme. There's also other initiatives such as OAuth used by (among other things) OpenSocial.
Re: ChallengeResponse with multiple url-patterns
Hi Jerome, Thanks for the response, I think that clears it up! Cheers, Dustin Jerome Louvel wrote: Hi Dustin, Restlet has its own separate mechanism to authenticate HTTP requests. When you deploy your Restlet application inside a Servlet container, we recommend to use Restlet mechanisms instead (Guard, etc.). Otherwise, the required HTTP headers are probably consumed by the Servlet container before the request reaches the Restlet adapter. I hope it helps explaining the observed behavior. Best regards, Jerome -Message d'origine- De : Dustin N. Jenkins [mailto:[EMAIL PROTECTED] Envoyé : jeudi 3 avril 2008 19:58 À : Restlet Users Group Objet : ChallengeResponse with multiple url-patterns I'm using JDK 1.5 with Resltet 1.0.9 in a Linux environment running Tomcat 5.5. I have multiple url-patterns in my security constraint as shown in this bit from my web.xml: SecurityConstraint /firstpattern/* /secondpattern/* public This works fine for the first pattern that is found, and I can call getRequest().getChallengeResponse().getIdentifier() to obtain the currently authenticated username. So if I call http://myhost/mywebapp/firstpattern/do I get challenged and it's fine. If do not close my browser and try to use the challenge response by calling http://myhost/mywebapp/secondpattern/do I am not challenged, as expected as I think it's cached somewhere, and then the getRequest().getChallengeResponse() returns a null. Is this according to spec? A bug? Or is it tied to the URL pattern somewhere only once per webapp? Thanks! Dustin -- Dustin N. Jenkins | Tel/Tél: 250.363.3101 | [EMAIL PROTECTED] facsimile/télécopieur: (250) 363-0045 National Research Council Canada | 5071 West Saanich Rd, Victoria BC. V9E 2E7 Conseil national de recherches Canada | 5071, ch. West Saanich, Victoria (C.-B) V9E 2E7 Government of Canada | Gouvernement du Canada -- Dustin N. Jenkins | Tel/Tél: 250.363.3101 | [EMAIL PROTECTED] facsimile/télécopieur: (250) 363-0045 National Research Council Canada | 5071 West Saanich Rd, Victoria BC. V9E 2E7 Conseil national de recherches Canada | 5071, ch. West Saanich, Victoria (C.-B) V9E 2E7 Government of Canada | Gouvernement du Canada
Re: Guarding all Resources using one Guard
Hi Surjendu,
On Apr 21, 2008, at 11:55 AM, Surjendu wrote:
Hi Barrie
Thanks for ur response. But the sample codebase Jerome suggested
does not work.
I did the following which did not work
Router router = new Router(getContext());
router.attach("/domain/{domainname}", DomainResource.class);
Guard guard = new
SamePageGuard(getContext(),ChallengeScheme.HTTP_BASIC);
guard.setNext(router);
return router;
You probably want to return the guard here.
Rhett
Re: Guarding all Resources using one Guard
Hi Barrie
Thanks for ur response. But the sample codebase Jerome suggested does not work.
I did the following which did not work
Router router = new Router(getContext());
router.attach("/domain/{domainname}", DomainResource.class);
Guard guard = new SamePageGuard(getContext(),ChallengeScheme.HTTP_BASIC);
guard.setNext(router);
return router;
But If i guard individual classes it works like a charm.(which i cannot do as I
have so many resource files...I cant create tons and tons of gurad class...)
Guard guard = new SamePageGuard(getContext(),ChallengeScheme.HTTP_BASIC);
Router router = new Router(getContext());
guard.setNext(DomainResource.class);
router.attach("/domain/{domainname}", guard);
return router;
Jerome/Barrie Plz respond.
Regards
Surjendu
Re: [JAX-RS] Spring based instantiation of resource and provider classes
Hi Stephan, What my changes introduce is the possibility of taking over the instantiation of the resource and provider classes, so that it is no longer hard-coded that the jax-rs code does this. In itself, there's nothing Spring-specific to this patch. After having a quick look at org.restlet.ext.spring_2.5, it is easy to imagine more Spring-specific features. For example a SpringJaxRsApplication which scans the Spring bean container in which it is defined for all beans which are JAX-RS resource classes. Or which uses that Spring-container to instantiate the JAX-RS classes. But those are already higher-level integration scenario's and I wouldn't look into that yet. BTW, in my patch I've only foreseen the possibility to set the "ComponentProvider" on the JaxRsRouter class. If you're OK with this patch, I would look into adding this on JaxRsApplication too, as that is what most people will be using. I'm currently working in a scenario where I want to be able to create multiple JaxRsRouter's within one application, therefore I'm working directly with JaxRsRouter. Best regards, Bruno. On Mon, 2008-04-21 at 17:44 +0200, Stephan Koops wrote: > Hi Bruno, > > I've no experience with Spring until now. I will take a look into it > tomorrow. Does your approach fit the spring approach > (org.restlet.ext.spring_2.5) in Restlet? > > best regards >Stephan > > Bruno Dumon schrieb: > > Hi, > > > > Working with JAX-RS, I'm seeing the need to be able to inject > > dependencies (typically Spring-managed beans) in the resource classes. > > > > I've done a bit of research on this topic, and found out the following: > > > > * this need has come up before in JAX-RS circles (see the mailing lists > > & blogs) > > > > * there's no official JAX-RS solution yet, as for the generic case > > there are some issues to resolve, for example both JAX-RS and Spring can > > do constructor based injection. > > > > * Jersey allows to provide a "ComponentProvider" responsible for > > getting the instantiated bean [1]. Based on this, they have a branch [2] > > where they're working on further Spring integration. Based on the > > insights gained there, maybe the JAX-RS spec will evolve to a more > > IoC-friendly model. > > > > The Restlet JAX-RS extension has no support yet for plugging in custom > > ways of instantiating the resource classes. Since I really wanted such a > > feature, I've gone ahead and added it. > > > > You can find it in the attached patch. > > > > This doesn't include anything Spring-specific, but based on this > > interface, one can use Spring's AutowireCapableBeanFactory.createBean() > > method to let Spring instantiate the resource classes and inject > > dependencies into them (as indicated with the @Autowire annotation). > > Other approaches are also possible. > > > > I'm looking forward to any comments on this, I hope it's possible to > > include this feature or something similar in Restlet. > > > > [1] > > https://jersey.dev.java.net/source/browse/jersey/trunk/jersey/src/spi/com/sun/ws/rest/spi/service/ComponentProvider.java?rev=879&view=markup > > [2] > > https://jersey.dev.java.net/source/browse/jersey/branches/spring-integration/ > > -- Bruno Dumon http://outerthought.org/ Outerthoughthttp://www.daisycms.org/ [EMAIL PROTECTED] http://www.kauriproject.org/
Placing information in HttpServletRequest
Hi,
In my restlet code, I am looking toward placing some information in the
HttpServletRequest. From an org.restlet.data.Request object, I am doing the
following:
public HttpServletRequest getHttpServletRequest(Request request) {
if (!(request instanceof HttpRequest)) {
throw new RuntimeException("Request is not a HttpRequest");
}
HttpRequest httpReq = (HttpRequest) request;
HttpCall call = httpReq.getHttpCall();
if (!(call instanceof ServletCall)) {
throw new RuntimeException("Call is not a ServletCall");
}
ServletCall serverCall = (ServletCall) call;
HttpServletRequest httpServletRequest = serverCall.getRequest();
return httpServletRequest;
}
I am not sure if this is the best way to accomplish something like this. Not
pleased at the punch on the casting needs.I know that one can place
information in the HttpHeaders using something like:
Series headers = new Form();
headers.add("Foo", "Bar");
request.getAttributes().set("org.restlet.http.headers", headers);
Is there an equivalent way to handle HttpServlet attributes?
Thanks,
Sanjay
_
Going green? See the top 12 foods to eat organic.
http://green.msn.com/galleries/photos/photos.aspx?gid=164&ocid=T003MSN51N1653A
Re: File extensions are not taken...
> I think that your problem has been fixed and is available : > - via the download page [2], and get the unstable version. It didn't work > application.getTunnelService().setExtensionsTunnel(false); Yes it was that Thanks a lot guys
Re: File extensions are not taken...
Hi Tom,
I suppose that "documentFileRestlet" is an instance of the "Directory"
restlet.
Your problem must be due to a new feature called "extensions filter"
(see [1]).
I think that your problem has been fixed and is available :
- in the svn repository, or
- via the download page [2], and get the unstable version.
Otherwise, you can turn off the extensions filter at the level of the
application:
application.getTunnelService().setExtensionsTunnel(false);
Otherwise, you can declare all "knwon" extensions manually at the level
of the application:
application.getMetadataService().addExtension("rtf", new
MediaType("application/rtf"));
best regards,
Thierry Boileau
[1] http://restlet.tigris.org/issues/show_bug.cgi?id=463
[2] http://www.restlet.org/downloads/
Hello,
Since I got Restlet 1.1M3 I have noticed a problem with file extensions.
I use Tomcat 5.5.
The code is :
Router router = new Router(getContext());
router.attach("/documents/{reference}/files/{fileName}", documentFileRestlet);
This url doesn't work :
http://machine:8080/myservice/documents/EM.0271951/files/test2.rtf
The log is : 8080 GET /myservice/documents/EM.0271951/files/test2
- 200 41 - 9641...
But it works if I encode the dot "." in hexa code %2E :
http://machine:8080/myservice/documents/EM.0271951/files/test2%2Ertf
And it worked very well with 1.0.9
What is the problem ?
Thank you.
Re: [JAX-RS] Spring based instantiation of resource and provider classes
Hi Bruno, I've no experience with Spring until now. I will take a look into it tomorrow. Does your approach fit the spring approach (org.restlet.ext.spring_2.5) in Restlet? best regards Stephan Bruno Dumon schrieb: Hi, Working with JAX-RS, I'm seeing the need to be able to inject dependencies (typically Spring-managed beans) in the resource classes. I've done a bit of research on this topic, and found out the following: * this need has come up before in JAX-RS circles (see the mailing lists & blogs) * there's no official JAX-RS solution yet, as for the generic case there are some issues to resolve, for example both JAX-RS and Spring can do constructor based injection. * Jersey allows to provide a "ComponentProvider" responsible for getting the instantiated bean [1]. Based on this, they have a branch [2] where they're working on further Spring integration. Based on the insights gained there, maybe the JAX-RS spec will evolve to a more IoC-friendly model. The Restlet JAX-RS extension has no support yet for plugging in custom ways of instantiating the resource classes. Since I really wanted such a feature, I've gone ahead and added it. You can find it in the attached patch. This doesn't include anything Spring-specific, but based on this interface, one can use Spring's AutowireCapableBeanFactory.createBean() method to let Spring instantiate the resource classes and inject dependencies into them (as indicated with the @Autowire annotation). Other approaches are also possible. I'm looking forward to any comments on this, I hope it's possible to include this feature or something similar in Restlet. [1] https://jersey.dev.java.net/source/browse/jersey/trunk/jersey/src/spi/com/sun/ws/rest/spi/service/ComponentProvider.java?rev=879&view=markup [2] https://jersey.dev.java.net/source/browse/jersey/branches/spring-integration/
[JAX-RS] Spring based instantiation of resource and provider classes
Hi,
Working with JAX-RS, I'm seeing the need to be able to inject
dependencies (typically Spring-managed beans) in the resource classes.
I've done a bit of research on this topic, and found out the following:
* this need has come up before in JAX-RS circles (see the mailing lists
& blogs)
* there's no official JAX-RS solution yet, as for the generic case
there are some issues to resolve, for example both JAX-RS and Spring can
do constructor based injection.
* Jersey allows to provide a "ComponentProvider" responsible for
getting the instantiated bean [1]. Based on this, they have a branch [2]
where they're working on further Spring integration. Based on the
insights gained there, maybe the JAX-RS spec will evolve to a more
IoC-friendly model.
The Restlet JAX-RS extension has no support yet for plugging in custom
ways of instantiating the resource classes. Since I really wanted such a
feature, I've gone ahead and added it.
You can find it in the attached patch.
This doesn't include anything Spring-specific, but based on this
interface, one can use Spring's AutowireCapableBeanFactory.createBean()
method to let Spring instantiate the resource classes and inject
dependencies into them (as indicated with the @Autowire annotation).
Other approaches are also possible.
I'm looking forward to any comments on this, I hope it's possible to
include this feature or something similar in Restlet.
[1]
https://jersey.dev.java.net/source/browse/jersey/trunk/jersey/src/spi/com/sun/ws/rest/spi/service/ComponentProvider.java?rev=879&view=markup
[2]
https://jersey.dev.java.net/source/browse/jersey/branches/spring-integration/
--
Bruno Dumon http://outerthought.org/
Outerthoughthttp://www.daisycms.org/
[EMAIL PROTECTED] http://www.kauriproject.org/
Index: modules/org.restlet.ext.jaxrs_0.9/src/org/restlet/ext/jaxrs/JaxRsRouter.java
===
--- modules/org.restlet.ext.jaxrs_0.9/src/org/restlet/ext/jaxrs/JaxRsRouter.java (revision 3061)
+++ modules/org.restlet.ext.jaxrs_0.9/src/org/restlet/ext/jaxrs/JaxRsRouter.java (working copy)
@@ -172,6 +172,8 @@
@SuppressWarnings("unchecked")
private final ThreadLocalizedContext tlContext = new ThreadLocalizedContext();
+private ComponentProvider componentProvider;
+
/**
* Creates a new JaxRsRouter with the given Context. Only the default
* providers are loaded. If a resource class later wants to check if a user
@@ -337,7 +339,7 @@
Provider provider;
try {
provider = new Provider(jaxRsProviderClass, tlContext,
-this.entityProviders, contextResolvers);
+this.entityProviders, contextResolvers, componentProvider);
} catch (InstantiateException e) {
String msg = "Ignore provider " + jaxRsProviderClass.getName()
+ "Could not instantiate the Provider, class "
@@ -514,7 +516,7 @@
ResourceObject o;
try {
o = rrc.createInstance(tlContext, entityProviders,
-contextResolvers, getLogger());
+contextResolvers, componentProvider, getLogger());
} catch (WebApplicationException e) {
throw e;
} catch (NoMessageBodyReaderException e) {
@@ -1132,4 +1134,12 @@
uris.add(rrc.getPathRegExp().getPathPattern());
return Collections.unmodifiableCollection(uris);
}
+
+public ComponentProvider getComponentProvider() {
+return componentProvider;
+}
+
+public void setComponentProvider(ComponentProvider componentProvider) {
+this.componentProvider = componentProvider;
+}
}
\ No newline at end of file
Index: modules/org.restlet.ext.jaxrs_0.9/src/org/restlet/ext/jaxrs/internal/wrappers/RootResourceClass.java
===
--- modules/org.restlet.ext.jaxrs_0.9/src/org/restlet/ext/jaxrs/internal/wrappers/RootResourceClass.java (revision 3061)
+++ modules/org.restlet.ext.jaxrs_0.9/src/org/restlet/ext/jaxrs/internal/wrappers/RootResourceClass.java (working copy)
@@ -44,6 +44,7 @@
import org.restlet.ext.jaxrs.internal.util.PathRegExp;
import org.restlet.ext.jaxrs.internal.util.Util;
import org.restlet.ext.jaxrs.internal.wrappers.provider.EntityProviders;
+import org.restlet.ext.jaxrs.ComponentProvider;
/**
* Instances represents a root resource class, see chapter 3 of JAX-RS
@@ -133,6 +134,8 @@
*[EMAIL PROTECTED] org.restlet.ext.jaxrs.JaxRsRouter}.
* @param allResolvers
*all available [EMAIL PROTECTED] ContextResolver}s.
+ * @param componentProvider
+ *object responsible for instantiating the resource class. Optional, thus can be null.
* @param logger
*The logger to use
* @return
@@ -149,21 +152,23 @@
*/
publ
Re: File extensions are not taken...
Hi Tom,
in Restlet 1.1 a feature to use virtual file extensions for content
negotiation was added. Because someone (look around, but there are only
me :-) ) unfortunately checked in a diasabled test method a bug was not
found before Restlet 1.1 M3 was released. AFAIK it is fixed now. You can
try an development version (see http://www.restlet.org/downloads/). You
could also wait for Restlet 1.1 M4 (see also
http://www.restlet.org/about/roadmap)
best regards
Stephan
Tom schrieb:
Hello,
Since I got Restlet 1.1M3 I have noticed a problem with file extensions.
I use Tomcat 5.5.
The code is :
Router router = new Router(getContext());
router.attach("/documents/{reference}/files/{fileName}", documentFileRestlet);
This url doesn't work :
http://machine:8080/myservice/documents/EM.0271951/files/test2.rtf
The log is : 8080 GET /myservice/documents/EM.0271951/files/test2
- 200 41 - 9641...
But it works if I encode the dot "." in hexa code %2E :
http://machine:8080/myservice/documents/EM.0271951/files/test2%2Ertf
And it worked very well with 1.0.9
What is the problem ?
Thank you.
File extensions are not taken...
Hello,
Since I got Restlet 1.1M3 I have noticed a problem with file extensions.
I use Tomcat 5.5.
The code is :
Router router = new Router(getContext());
router.attach("/documents/{reference}/files/{fileName}", documentFileRestlet);
This url doesn't work :
http://machine:8080/myservice/documents/EM.0271951/files/test2.rtf
The log is : 8080 GET /myservice/documents/EM.0271951/files/test2
- 200 41 - 9641...
But it works if I encode the dot "." in hexa code %2E :
http://machine:8080/myservice/documents/EM.0271951/files/test2%2Ertf
And it worked very well with 1.0.9
What is the problem ?
Thank you.
application/*+xml with attachment
now with attachments
Stephan
Stephan Koops schrieb:
Hi,
Restlet do not support the media type "application/*+xml" yet. It is
not yet available as constant and not supported by
MediaType.includes(MediaType).
I've created a patch for MediaType and MediaTypeTestCase for this.
The media type is also required for JAX-RS.
I don't know if "application/*+xml" includes also "application/xml".
If you look only to the syntax, then not, so I've not implemented it.
The MediaTypeTestCase contains test code for this case, but it will be
ignored by if(false). If it is not needed, throw it away.
best regards
Stephan
Index: modules/org.restlet.test/src/org/restlet/test/MediaTypeTestCase.java
===
--- modules/org.restlet.test/src/org/restlet/test/MediaTypeTestCase.java
(revision 3057)
+++ modules/org.restlet.test/src/org/restlet/test/MediaTypeTestCase.java
(working copy)
@@ -77,6 +77,22 @@
assertTrue(mt2.includes(mt2));
assertTrue(mt1.includes(mt2));
assertFalse(mt2.includes(mt1));
+
+if (false) { // TODO do "app/*+xml" includes "app/xml"? is not yet
implemented.
+mt1 = MediaType.APPLICATION_ALL_XML;
+mt2 = MediaType.APPLICATION_XML;
+assertTrue(mt1.includes(mt1));
+assertTrue(mt2.includes(mt2));
+assertTrue(mt1.includes(mt2));
+assertFalse(mt2.includes(mt1));
+}
+
+mt1 = MediaType.APPLICATION_ALL_XML;
+mt2 = MediaType.APPLICATION_ATOM_SERVICE_XML;
+assertTrue(mt1.includes(mt1));
+assertTrue(mt2.includes(mt2));
+assertTrue(mt1.includes(mt2));
+assertFalse(mt2.includes(mt1));
}
public void testMostSpecificMediaType() {
Index: modules/org.restlet/src/org/restlet/data/MediaType.java
===
--- modules/org.restlet/src/org/restlet/data/MediaType.java (revision 3058)
+++ modules/org.restlet/src/org/restlet/data/MediaType.java (working copy)
@@ -43,6 +43,9 @@
public static final MediaType APPLICATION_ALL = register("application/*",
"All application documents");
+public static final MediaType APPLICATION_ALL_XML = register(
+"application/*+xml", "All application/*+xml documents");
+
public static final MediaType APPLICATION_ATOM_SERVICE_XML = register(
"application/atomsvc+xml", "Atom service documents");
@@ -562,9 +565,16 @@
if (!result) {
// Both media types are different
-result = getMainType().equals(included.getMainType())
-&& (getSubType().equals(included.getSubType()) ||
getSubType()
-.equals("*"));
+if (this.getMainType().equals(included.getMainType())) {
+if (this.getSubType().equals(included.getSubType())) {
+result = true;
+} else if (this.getSubType().equals("*")) {
+result = true;
+} else if (this.getSubType().equals("*+xml")
+&& included.getSubType().endsWith("+xml")) {
+result = true;
+}
+}
}
return result;
application/*+xml
Hi, Restlet do not support the media type "application/*+xml" yet. It is not yet available as constant and not supported by MediaType.includes(MediaType). I've created a patch for MediaType and MediaTypeTestCase for this. The media type is also required for JAX-RS. I don't know if "application/*+xml" includes also "application/xml". If you look only to the syntax, then not, so I've not implemented it. The MediaTypeTestCase contains test code for this case, but it will be ignored by if(false). If it is not needed, throw it away. best regards Stephan
Re: Fix for some jaxrs extension pom errors
Hi Bruno, thanks for reporting and fixing this issue. I've updated the svn repository. best regards, Thierry Boileau Hi again, The change of last week to add the missing dependencies to the jaxrs extension pom was not good enough, as more is needed to get the version properties actually substituted. It's only now that I'm trying this out... Maybe we should have a more dynamic mechanism for this. The json artifactId was also wrong (at least for how Restlet names it). See attached patch for fixes. BTW, the *.pom files and the build.xml are missing svn:eol-style properties, causing them to have dos line endings on my linux system.
Fix for some jaxrs extension pom errors
Hi again, The change of last week to add the missing dependencies to the jaxrs extension pom was not good enough, as more is needed to get the version properties actually substituted. It's only now that I'm trying this out... Maybe we should have a more dynamic mechanism for this. The json artifactId was also wrong (at least for how Restlet names it). See attached patch for fixes. BTW, the *.pom files and the build.xml are missing svn:eol-style properties, causing them to have dos line endings on my linux system. -- Bruno Dumon http://outerthought.org/ Outerthoughthttp://www.daisycms.org/ [EMAIL PROTECTED] http://www.kauriproject.org/ Index: build/tmpl/poms/org.restlet.ext.jaxrs.pom === --- build/tmpl/poms/org.restlet.ext.jaxrs.pom (revision 3057) +++ build/tmpl/poms/org.restlet.ext.jaxrs.pom (working copy) @@ -26,7 +26,7 @@ org.json - json + org.json @lib-json-version@ @@ -50,4 +50,4 @@ - \ No newline at end of file + Index: build/build.xml === --- build/build.xml (revision 3057) +++ build/build.xml (working copy) @@ -682,6 +682,8 @@ + + @@ -704,6 +706,8 @@ + + @@ -924,7 +928,7 @@ - +
RE: Dependencies in JAX-RS extension pom
On Sat, 2008-04-19 at 18:14 +0200, Jerome Louvel wrote: > Hi Bruno, > > After thinking more about this issue, here are the aspects I took into > account: > [snip] > -- > > So, I have updated the SVN trunk following the above approach. Let me know > if I missed something important. > This all sounds good, thanks for taking care of this. -- Bruno Dumon http://outerthought.org/ Outerthoughthttp://www.daisycms.org/ [EMAIL PROTECTED] http://www.kauriproject.org/
