Hello,
1/
basically a Guard is a filter. As said in the tutorial, a filter is able
to pre-process (or 'post-process") a request (it can update it) before
transmitting the request to the the next Restlet.
The main idea is that the set of your resources defines a graph where
the branches are called "routes". That is to say, the main job of your
application (in the Application#createRoot method) is to define the
routes it will manage.
Then, your are totally free to put a filter (a guard, for example) on a
given route.
Classically, your application looks like that:
public Restlet createRoot() {
Router router = new Router(getContext());
router.attach("/path1", Resource1.class); // Defines route #1 to a
Resource
router.attach("/path2", Resource2.class); // Defines route #2 to a
Resource
router.attach("/path3", restlet1); // Defines route #3 to an instance
of the Restlet class or subclass
Router router2 = new Router(getContext()); // Will handle a whole
part of the graph
router.attach("/path4", router2); // Defines route #4 to a new Router
router2.attach("/path5", Resource3.class); // Defines route #5
("/path4/path5", actually)
[...]
return router;
}
If you want to Guard some routes, you have to define the routes and
insert the guard instance properly as explained in the tutorial:
router.attach("/path4", guard);
guard.setNext(router2);
2/ No you don't have to systematically preload the login/password.
There several ways to check the given login/password. By default, a
guard looks into its list of secrets. But you can also override the
"checkSecret" method [3] which gives you a way to check the given
login/password pair in the way you want.
You can have a look at the user guide (a link is present on the
"documentation" page) [1] and at the javadocs [2].
3/ As said previously, a Guard is a filter, designed to be put before a
given graph of routes. It handles the request before the final leaf (a
Resource instance or a Restlet instance) does so.
I hope this will help you.
Best regards,
Thierry Boileau
[1] http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet.html
[2] http://www.restlet.org/documentation/1.1/api/org/restlet/Guard.html
[3]
http://www.restlet.org/documentation/1.1/api/org/restlet/Guard.html#checkSecret(org.restlet.data.Request,%20java.lang.String,%20char[])
> I've read the tutorial, but it doesn't answer all my questions.
>
> 1) Where do I set the Guard? I only need it on a couple of resources, so I
> was thinking I should create it in the constructor for the Resource. Does
> this seem logical/reasonable?
>
> 2) The example shows a call to getSecrets().put(). Does this mean I have to
> preload all my credentials when I create the Guard? I was hoping I could
> just grab the client-supplied username and password and let my own code
> decide if the user should be allowed in.
>
> 3) How does the flow work with challenges? Maybe this is related to question
> #1 above, but how does the Guard intercept the request, send the challenge,
> and then accept the new request without the Resource going away or being
> re-created? Especially with Digest, I dont think you'd want to re-create the
> Guard else the nonce would likely change?
>
> Any help or guidance would be appreciated!
>
> Mike
>
> ------------------------------------------------------
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1304872
>
>
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1307239
