Hi Steve,
I have never tried this before but I am willing to throw out an idea or two that you could try
. Actually it's only really a half idea as it only addresses announcements.
Liferay ships with a REST-like service implementation for most of the services API. Assuming you are using the Tomcat bundle on 8080, on your local machine you can see the listing of the services by going to
If you enter announcements into the search field you will find that there are several options, one of which includes AnnouncementsEntry, add-entry. This might help you to acheive the first half of your question (always assuming that the external system can access the Liferay system of course).
Can you give that shot and let us know if it helps? If it does then perhaps you could do something similar for alerts using a Struts Action hook or something.
I have never tried this before but I am willing to throw out an idea or two that you could try
. Actually it's only really a half idea as it only addresses announcements. Liferay ships with a REST-like service implementation for most of the services API. Assuming you are using the Tomcat bundle on 8080, on your local machine you can see the listing of the services by going to
http://localhost:8080/api/jsonws
If you enter announcements into the search field you will find that there are several options, one of which includes AnnouncementsEntry, add-entry. This might help you to acheive the first half of your question (always assuming that the external system can access the Liferay system of course).
Can you give that shot and let us know if it helps? If it does then perhaps you could do something similar for alerts using a Struts Action hook or something.
Hi Steve,
I've never used your configuration before so I'm not entirely sure how to work around it. I can tell you that in the past though I have used curl to execute this things. In fact, I have used curl to access non jsonws urls that are secure as well. It just meant that I had to first curl the auth url with credentials and then iunclude the resulting cookie in subsequent requests to perform them as the authenticate user.
Do you think something like that might work for your setup?
As for the second part of your question, it's a little more involved. I would wait to address that part until you got past the CAS bit. For the record though the p_auth token is not a work around for login. Its a token that is generated by liferay for action requests to help prevent CSRF attacks.
Let's start with the CAS bit and get past that first. Forget Liferay for a second, can you authenticate against your CAS server using something like curl? (I know you might not use curl in your final solution, but it would allow use to determine if there was a way to get an authenticated session without going through th GUI).
I've never used your configuration before so I'm not entirely sure how to work around it. I can tell you that in the past though I have used curl to execute this things. In fact, I have used curl to access non jsonws urls that are secure as well. It just meant that I had to first curl the auth url with credentials and then iunclude the resulting cookie in subsequent requests to perform them as the authenticate user.
Do you think something like that might work for your setup?
As for the second part of your question, it's a little more involved. I would wait to address that part until you got past the CAS bit
. For the record though the p_auth token is not a work around for login. Its a token that is generated by liferay for action requests to help prevent CSRF attacks. Let's start with the CAS bit and get past that first. Forget Liferay for a second, can you authenticate against your CAS server using something like curl? (I know you might not use curl in your final solution, but it would allow use to determine if there was a way to get an authenticated session without going through th GUI).
Hi Steve,
I can try to explain some of them but I am not familiar with all of them. You may need to hopw someone else fills in the blanks or do a little digging
p_auth (maybe this can help getting around CAS?)
This is something that is generated by Liferay to help prevent CSRF attacks. It's only application for Action URLs. I believe there is a way to generate this using JS for initial calls. The documentation should cover how this works and how to use it.
plid
This is the page layout id. A "page" created in the portal is referred to as a Layout (in the API). Each layout has a unique identifier... and this is the plid. The importance of this field is that it tells the portal which "page" you want to route a request to .Imagine you have PortletX and this portlet has been added to 3 different pages. You might want to create a PORTLET request that targets PortletX, but on a specific page. The plid ensures that "page" is the one that gets the request. (incidentally, the p_p_id is the portlet is which is the portlet on the plid that would get the request).
classNameId
There is a table in the database called ClassName_. In this table you will find the id (referenced here) and the corresponding model object. This is the way that Liferay is able to use one database table for multiple types of "objects". So imagine that you have a table that stores some "generic" information related to a model. You can use the classNameId as the "model" reference -- think of it like a foreign key, though there is no FK. It's implicit.
classPK
This is a reference to the ACTUAL record. So if you have a User model object with a classNameId of 1123 ... and then 3 user records in the User table 111, 222, 333, then this column specifies that this record is in reference to, for example, user 333.
url
Not sure about this one. Perhaps it's just where you want to take the user in reference to the alert? For example, you get a notification that you have a new workflow task to approve something... perhaps this url can take you directly to the item?
type
Not sure but I would assume that it has soemthing to do with the type (duh) of notification -- for eg, Info, Warn, Error .. that kind of thing. Totally guessing though.
priority
Should be pretty self explanatory I think.. probably just how high in a list it has to appear. Maybe it has something to do with the rendering (red versus green text or soemthing?)
alert
I think this would determine whether or not it shows up in teh alerts portlet but again, I am not sure.
Best thing to do at this stage is to have a poke through the Portal's source code to see what shows up. For the views you will find them under ROOT/html/portlet ... the implementation classes should be in the portal-impl project (com.liferay.portlet.*). Liferay does a really good job (I think) of making their source coude and packaging semantic so it should be pretty easy to work through.
I can try to explain some of them but I am not familiar with all of them. You may need to hopw someone else fills in the blanks or do a little digging
p_auth (maybe this can help getting around CAS?)
This is something that is generated by Liferay to help prevent CSRF attacks. It's only application for Action URLs. I believe there is a way to generate this using JS for initial calls. The documentation should cover how this works and how to use it.
plid
This is the page layout id. A "page" created in the portal is referred to as a Layout (in the API). Each layout has a unique identifier... and this is the plid. The importance of this field is that it tells the portal which "page" you want to route a request to .Imagine you have PortletX and this portlet has been added to 3 different pages. You might want to create a PORTLET request that targets PortletX, but on a specific page. The plid ensures that "page" is the one that gets the request. (incidentally, the p_p_id is the portlet is which is the portlet on the plid that would get the request).
classNameId
There is a table in the database called ClassName_. In this table you will find the id (referenced here) and the corresponding model object. This is the way that Liferay is able to use one database table for multiple types of "objects". So imagine that you have a table that stores some "generic" information related to a model. You can use the classNameId as the "model" reference -- think of it like a foreign key, though there is no FK. It's implicit.
classPK
This is a reference to the ACTUAL record. So if you have a User model object with a classNameId of 1123 ... and then 3 user records in the User table 111, 222, 333, then this column specifies that this record is in reference to, for example, user 333.
url
Not sure about this one. Perhaps it's just where you want to take the user in reference to the alert? For example, you get a notification that you have a new workflow task to approve something... perhaps this url can take you directly to the item?
type
Not sure but I would assume that it has soemthing to do with the type (duh) of notification -- for eg, Info, Warn, Error .. that kind of thing. Totally guessing though.
priority
Should be pretty self explanatory I think.. probably just how high in a list it has to appear. Maybe it has something to do with the rendering (red versus green text or soemthing?)
alert
I think this would determine whether or not it shows up in teh alerts portlet but again, I am not sure.
Best thing to do at this stage is to have a poke through the Portal's source code to see what shows up. For the views you will find them under ROOT/html/portlet ... the implementation classes should be in the portal-impl project (com.liferay.portlet.*). Liferay does a really good job (I think) of making their source coude and packaging semantic so it should be pretty easy to work through.
Hi Andrew,
Ok THANKS !
I successfully sent an alert and an announcement using the api and your latest explanations
I will try to send announcements using different scopes like mentioned (not the classNameId for the general scope like I did but with a classNameId for Groups, Roles, ...)
Thank you very much for your time and your help !
Have a nice day,
Julien
Ok THANKS !
I successfully sent an alert and an announcement using the api and your latest explanations
I will try to send announcements using different scopes like mentioned (not the classNameId for the general scope like I did but with a classNameId for Groups, Roles, ...)
Thank you very much for your time and your help !
Have a nice day,
Julien