RE: Error form HttpConverter
We where able to finally narrow down the issue to firewall rules that can causing some part of the code to fail. However the last question, should we remove the following code? esponseHeaders.add(Cache-Control, no-cache); responseHeaders.add(Pragma, no-cache); responseHeaders.add(Expires, 0); THanks for you help. rgds, vinoo -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1973713
RE: Re: Questions about HTTP Authentication
I was looking with the getCredentials... the password is ok on the char[] secret thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1971978
RE: Re: securing the whole application
Just one more question: Let say that I have the resource User.
GET user/{username} - get the user representation identified by {username}
I want to filter the information sent back in the Representation of the user,
for example: Let say the user is authenticated in and he requests his profile
by using GET user/{username}. He can get all the information of the user
profile and even put some modifications back. However if the user is
authenticated, he can get only a limited set of that same information and
cannot put any kind of change.
What is the best approach to deal with this?
One alternative may be to have two different representations: One for
authenticated users and other for not authenticated users? In this case may
we have a Guard, that authenticates the user based on a cookie, for example,
and forward the request to the same restlet but to generate different
representations based on the outcome of the authentication?
May I have your opinions or known best practices around my issue?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1967653
RE: Re: securing the whole application
Sure it helped. Thanks. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1967245
Re: Error form HttpConverter
Hello Vinoo,
at least, you must remove responseHeaders.add(Expires, 0);
because it's forbidden and replace it by a call to
Representation#setExpirationDate() as pointed by Jerome.
Having said that, I think you can remove the code, or let it and set the
expiration date with the current date.
best regards,
Thierry Boileau
I have also a few very minor remarks on your code:
- you can replace org.restlet.http.headers by
HttpConstants.ATTRIBUTE_HEADERS (if 1.1 rc2 allows it)
- I'm not sure it's good pratice to have one Resource class that handle
/products and /products/{assetId}
We where able to finally narrow down the issue to firewall rules that can
causing some part of the code to fail.
However the last question, should we remove the following code?
responseHeaders.add(​Cache-Control, no-cache);
responseHeaders.add(Pragma, no-cache);
responseHeaders.add(Expires, 0);
THanks for you help.
rgds,
vinoo
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1973713
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1977293
Re: Questions about HTTP Authentication
Hello,
yes I tried to use getSecret() but with no success. Here the results
of my testing:
the code that tries to read the secret:
if (getRequest().getChallengeResponse() != null) {
l
.debug
(getCredentials
():+getRequest().getChallengeResponse().getCredentials());
l
.debug
(getIdentifier
():+getRequest().getChallengeResponse().getIdentifier());
l
.debug
(getPrincipal():+getRequest().getChallengeResponse().getPrincipal());
l.debug(getScheme():+getRequest().getChallengeResponse().getScheme());
l
.debug
(getSecret
():+getRequest().getChallengeResponse().getSecret().toString());
}
the output:
14:20:19,218 DEBUG TestResource:66 - getCredentials():dXNlcjp0ZXN0
14:20:19,218 DEBUG TestResource:67 - getIdentifier():user
14:20:19,218 DEBUG TestResource:68 - getPrincipal():user
14:20:19,218 DEBUG TestResource:69 - getScheme():HTTP_Basic
14:20:19,218 DEBUG TestResource:70 - getSecret():[...@d5a2a9
The input was username user and password test.
To test it I used the RESTClient (available at
http://code.google.com/p/rest-client/)
with the following settings for authentication:
Auth Type : Basic. Preemtive, Username user Password test
any ideas?
Best Regards,
mstricker
Am 28.04.2009 um 11:36 schrieb Thierry Boileau (via Nabble):
Hello,
did you try with simple calls to ChallengeResponse#getIdentifier and
ChallengeResponse#getSecret()?
I check these methods and they return the login and password in clear.
Best regards,
Thierry Boileau
Hi,
i found that my Client sends the Basic HTTP Authentication as Base64
encoded String containing username + : + pass
I decode it in this way:
public static boolean authenticate(ChallengeResponse challenge) {
if (challenge != null) {
String username = ;
String password = ;
BASE64Decoder decoder = new BASE64Decoder();
try {
logger.debug(Credentials:
+challenge.getCredentials());
String usernpass = new
String(decoder.decodeBuffer(challenge.getCredentials().toString()));
username = usernpass.substring(0,
usernpass.indexOf(:));
password =
usernpass.substring(usernpass.indexOf(:)
+ 1);
boolean auth = User.authenticate(username,
password);
logger.debug(auth);
return auth;
} catch (IOException ex) {
return false;
}
} else {
return false;
}
}
Am 27.04.2009 um 17:54 schrieb João Pereira (via Nabble):
Hi,
I'm also facing the same problem. The credentials and secret are
not
in clear text.
I've created a guard and override the public boolean
checkSecret(Request request, String identifier, char[] secret)
However the secret and
request.getChallengeResponse().getCredentials() are not in plain
text. What the algorithm to decode to the original?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1947397
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1947397
View this message in context: Re: Questions about HTTP
Authentication
http://n2.nabble.com/Questions-about-HTTP-Authentication-tp2665559p2728071.html
Sent from the Restlet Discuss mailing list archive
http://n2.nabble.com/Restlet-Discuss-f1400322.html at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1961264
View message @
http://n2.nabble.com/Questions-about-HTTP-Authentication-tp2665559p2732364.html
To start a new topic under Restlet Discuss, email
ml-node+1400322-1291817...@n2.nabble.com
To unsubscribe from Restlet Discuss, click here.
--
View this message in context:
http://n2.nabble.com/Questions-about-HTTP-Authentication-tp2665559p2740252.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1979051
RE: Re: securing the whole application
Hi Jao,
Personnally, I would handle this inside your target Resource (or
ServerResource in Restlet 1.2) subclass. Regarding the representation you
could have two or just one defined as a template representation (see
FreeMarker and Velocity extensions).
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : jp [mailto:joaomiguel.pere...@gmail.com]
Envoyé : mardi 28 avril 2009 21:42
À : discuss@restlet.tigris.org
Objet : RE: Re: securing the whole application
Just one more question: Let say that I have the resource User.
GET user/{username} - get the user representation identified by {username}
I want to filter the information sent back in the Representation of the
user, for example: Let say the user is authenticated in and he requests his
profile by using GET user/{username}. He can get all the information of the
user profile and even put some modifications back. However if the user is
authenticated, he can get only a limited set of that same information and
cannot put any kind of change.
What is the best approach to deal with this?
One alternative may be to have two different representations: One for
authenticated users and other for not authenticated users? In this case
may we have a Guard, that authenticates the user based on a cookie, for
example, and forward the request to the same restlet but to generate
different representations based on the outcome of the authentication?
May I have your opinions or known best practices around my issue?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=19676
53
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1982871
Re: let Resource return a gif image
Hi, thanks, it works perfectly. mstricker Am 29.04.2009 um 19:17 schrieb jlouvel (via Nabble): Hi Mike, You can simply directly return the image entity as the entity of your initial response. No need to convert to string. For example: getResponse().setEntity(response.getEntity()); Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : mstricker [mailto:m...@...] Envoyé : mercredi 29 avril 2009 17:13 À : disc...@... Objet : let Resource return a gif image Hi, currently I face a new problem using RESTlet where the internet could ot give me any hint on how to solve it. Basically I have a resource (lets call it /dynamicimage ) where on GET request I server-side have to contact another HTTP Server with some parameters that returns me a gif image. I tried this like this: Request request = new Request(Method.GET, http://otherserver/createimage?width=200;); request.setReferrerRef(http://mydevserver;); // Handle it using an HTTP client connector Client client = new Client(Protocol.HTTP); Response response = client.handle(request); System.out.println(response.getStatus()); this returns the correct response code(200) and response.getEntity().getText() gives cryptical chars that are the same as if I would save the dynamic image on my harddisk and open it with a texteditor. So until here all should work fine. Now my Server part does some other minor stuff (logging etc.) and at the end it should return this image. UsingStringRepresentation() and setting MediaType.IMAGE_GIF shows a corrupted image in the browser, using FileRepresentation and giving as path the remote location of the image does not produce any output. Is there a specific way how to attack this problem? I would like to avoid to save it serverside and redirect the client to the image. Any ideas? mstricker -- View this message in context: http://n2.nabble.com/let-Resource-return-a-gif-image-tp2741153p2741153.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=19811 02 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1982686 View message @ http://n2.nabble.com/let-Resource-return-a-gif-image-tp2741153p2741984.html To start a new topic under Restlet Discuss, email ml-node+1400322-1291817...@n2.nabble.com To unsubscribe from Restlet Discuss, click here. -- View this message in context: http://n2.nabble.com/let-Resource-return-a-gif-image-tp2741153p2743697.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1986340
