TL;DR
This is not a JSF or Java error, but a matter of internet security when trying to do Ajax for another domain.
Solutions include changing the target server to allow Ajax, using your server as a sort of intermediary to authenticate on the target server, or dynamically creating an HTML form on your page and doing an Submit on it.
The reason for the error
The error presented in the question says that the request (request) was not allowed (disallowed) for being for a different domain (cross-origin). When you try to make an Ajax for another domain, the default browser will deny this call for security reasons.
On the other hand, there is an exception to this rule, in case the other server returns specific headers like Access-Control-Allow-Origin
and Access-Control-Allow-Credentials
, which may authorise certain actions. Basically, before running Ajax, the browser makes a pre-check (pre-flight) looking for these headers. See how it works in the following diagram:
This article explains very well the question.
Solution #1 - Allow requests for another domain
The first solution is to change the target server to allow the necessary actions. This is explained in the article mentioned in the previous topic.
However, in your case it seems neither feasible nor possible, since this would have to be done on "any site" (see comment).
Solution #2 - Create an Intermediary Service
It could be an Ajax request to your own server, which would be completely allowed by the security rules, and then your server would make a request to the other site to authenticate and return the results to your page.
Think of a Servlet that works as a proxy or intermediary:
- It receives the POST request from Ajax
- Make a POST connection with the same data on the target site
- Get the answer from the site
- Returns the same answer to Ajax
Solution #3 - Using a hidden form
One last alternative would be to dynamically create a hidden form where:
- The
action
is the page of the other site that checks the login
- Login values go in fields
hidden
- The
target
is a iframe
also hidden, so as not to interfere with the local page
This answer in Stackoverflow develops this technique a little bit. It will only take a little more work to capture the return of Submit from within the form.
Sorry, but what is the reason for the post specifically?
– uaiHebert
I happen to have a login page, but one of the requirements I have is that the login can be done through a form located on any site. How will be traffic login and password, need to be via post.
– NilsonUehara
I already made my login screen receive the data via get and log in automatically... now I need to receive it via post for security (otherwise the data will be exposed in the URL)
– NilsonUehara
You couldn’t pass the values in the header then?
– uaiHebert
Pass header? What do you mean? It wouldn’t be the same as sending via GET. Ex: http://dominio.com.br/servico.jsf?var1=1&var2=x... ?
– NilsonUehara
When the form triggers the login call, you can use javascript/jquery/angular or add the header to the request. It is not the same as sending via GET because a HEADER does not go in the URL.
– uaiHebert
I’m gonna take a test...
– NilsonUehara
@uaiHebert could not, see the error that presents.
– NilsonUehara
Really, I ate fly in this. If I’m not mistaken, by ajax, you can’t redirect calls to other domains. -___-''
– uaiHebert
What I can think of then is you have a redirect to the site and the login be done on the site.
– uaiHebert
Well... today I have these two alternatives: Direct to the login page of the system or trigger the login via external site with the variables in the URL, via GET. But these forms are always questioned.
– NilsonUehara
I found Omnifaces (showcase.omnifaces.org/Components/viewParam) that can read attributes via POST, but apparently Omnifaces conflicts with the Openwebbeans (CDI) that I use.
– NilsonUehara
Passing via post you add a pseudo protection because the data will not be visible, for example, in the address bar and in the history, but an Attack "man in the Middle" can reveal the data if you are not using an encrypted connection (SSL or TLS for example). @uaiHebert you mean an http header? certainly not the appropriate way.
– Diego C Nascimento
On the second error, you will hardly get the browser to allow an HTTP cross-domain request. See for example: http://developer.chrome.com/extensions/xhr.html and http://en.wikipedia.org/wiki/Same_origin_policy
– Diego C Nascimento
As @Diegocnascimento said, your program is not related to JSF or Java, but rather to security restrictions on nevagadores that do not allow you to do Ajax for other domains via javascript.
– utluiz