留言板
How I can get p_auth param for an API
Hello community,
I'm actually developing a API to be used by a mobile app, then I need some frecuent methods like /login and /logout.
When you access into http://127.0.0.1:8080/api/jsonws/ and look for any available method, the client handle a p_auth param to do the request.
My question is how I can get that param and send in any request what I need??
I have understood that the p_auth param is always necesary to protect liferay from CSRF attacks, but I don´t want to send the credentials by http auth basic in any request I do.
Some suggestion??
I tested http://127.0.0.1:8080/api/jsonws/country/get-countries?p_auth=blablabla but it doesn´t work as I thought.
I'm actually developing a API to be used by a mobile app, then I need some frecuent methods like /login and /logout.
When you access into http://127.0.0.1:8080/api/jsonws/ and look for any available method, the client handle a p_auth param to do the request.
My question is how I can get that param and send in any request what I need??
I have understood that the p_auth param is always necesary to protect liferay from CSRF attacks, but I don´t want to send the credentials by http auth basic in any request I do.
Some suggestion??
I tested http://127.0.0.1:8080/api/jsonws/country/get-countries?p_auth=blablabla but it doesn´t work as I thought.
David H Nebinger，修改在8 年前。
RE: How I can get p_auth param for an API
Liferay Legend 帖子: 14919 加入日期: 06-9-2 最近的帖子
Right, because the auth token value is known on the server side.
When you log in, the auth cookie is set in the browser and that becomes the value sent in when the browser is doing the jsonws calls.
You too need to log in (whether using basic auth or otherwise) to get the value to pass in.
No, you will never be able to generate your own value and magically get by the login check.
If you could, that would immediately be flagged as a security vulnerability and would be shut down.
When you log in, the auth cookie is set in the browser and that becomes the value sent in when the browser is doing the jsonws calls.
You too need to log in (whether using basic auth or otherwise) to get the value to pass in.
No, you will never be able to generate your own value and magically get by the login check.
If you could, that would immediately be flagged as a security vulnerability and would be shut down.
David H Nebinger:
Right, because the auth token value is known on the server side.
When you log in, the auth cookie is set in the browser and that becomes the value sent in when the browser is doing the jsonws calls.
You too need to log in (whether using basic auth or otherwise) to get the value to pass in.
No, you will never be able to generate your own value and magically get by the login check.
If you could, that would immediately be flagged as a security vulnerability and would be shut down.
Hi,
Yes you´re right, It is not magic, I mean I used http://127.0.0.1:8080/api/jsonws/country/get-countries?p_auth=blablabla as an example, I entered to http://127.0.0.1:8080/api/jsonws/ previously logged in and I copied the p_auth param like p_auth=Kwt50sa... , and I tried to use it at the example url and It did not work.
Then I need a way to can get resources from the API by a token, without I have to send login credentials on the http headers in each request, but If you´re saying that p_auth works with the browser cookies, I'm sorry I have to develop my own api method to do that.
Thanks a lot for your answer.
I'm a newcommer in Liferay and a Junior Java developer too.
Regards.
Tomas Polesovsky，修改在8 年前。
RE: How I can get p_auth param for an API
Liferay Master 帖子: 676 加入日期: 09-2-13 最近的帖子
Hi Luis,
there are several methods you can use to authenticate your mobile client against portal.
1, Login form ... was designed for form-based authentication via browser
If a remote client use this kind of authentication, portal assumes you are browser and for API calls requires the p_auth token. This prevents CSRF attacks.
If you want to use it, you need to parse p_auth token from a portal page HTML.
2, HTTP Basic auth ... was designed for remote apps, requires portal to run on HTTPS
If you use HTTP Basic auth then you don't need p_auth token, however you need to send it with every API call.
3, Implement own token authorization
I'm sorry, portal currently has no token implementation that would be suitable for mobile apps. There is the infrastructure in place, but you would need to implement the actual token verification yourself.
there are several methods you can use to authenticate your mobile client against portal.
1, Login form ... was designed for form-based authentication via browser
If a remote client use this kind of authentication, portal assumes you are browser and for API calls requires the p_auth token. This prevents CSRF attacks.
If you want to use it, you need to parse p_auth token from a portal page HTML.
2, HTTP Basic auth ... was designed for remote apps, requires portal to run on HTTPS
If you use HTTP Basic auth then you don't need p_auth token, however you need to send it with every API call.
3, Implement own token authorization
I'm sorry, portal currently has no token implementation that would be suitable for mobile apps. There is the infrastructure in place, but you would need to implement the actual token verification yourself.
Tomas Polesovsky:
Hi Luis,
there are several methods you can use to authenticate your mobile client against portal.
1, Login form ... was designed for form-based authentication via browser
If a remote client use this kind of authentication, portal assumes you are browser and for API calls requires the p_auth token. This prevents CSRF attacks.
If you want to use it, you need to parse p_auth token from a portal page HTML.
2, HTTP Basic auth ... was designed for remote apps, requires portal to run on HTTPS
If you use HTTP Basic auth then you don't need p_auth token, however you need to send it with every API call.
3, Implement own token authorization
I'm sorry, portal currently has no token implementation that would be suitable for mobile apps. There is the infrastructure in place, but you would need to implement the actual token verification yourself.
I think I will chosse the opction 2.
Thanks a lot!!