Bug 1153618 - PicketLink should be configurable to ignore ajax calls
Summary: PicketLink should be configurable to ignore ajax calls
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: PicketLink
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: DR11
: EAP 6.4.0
Assignee: Peter Skopek
QA Contact: Ondrej Kotek
URL:
Whiteboard:
Depends On: 1164220
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-16 10:46 UTC by Peter Skopek
Modified: 2019-08-19 12:43 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-19 12:38:51 UTC
Type: Feature Request
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker EAP6-226 0 Major Closed PicketLink should be configurable to ignore ajax calls 2016-11-03 16:28:35 UTC

Description Peter Skopek 2014-10-16 10:46:24 UTC
1. Proposed title of this feature request

PicketLink should be able to ignore ajax requests

2. Who is the customer behind the request?
Account name: SMABTP
Customer segment:
TAM/SRM customer: no / yes
Strategic Customer yes/no: yes

3. What is the nature and description of the request?

Many application use ajax calls from the browser.
When the session has timed out, picketlink will cause a redirect to the login-server.

There are two issues here:

    the redirect is potentially cross-domain
    the ajax client receives the login page as response for which it is not coded

4. Why does the customer need this? (List the business requirements here)

programming ajax calls that need to go cross-platform is not trivial.

5. How would the customer like to achieve this? (List the functional
requirements here)

The request is to have a configuration switch that detects ajax calls. When such a call would arrive when there is not valid session, the server should not redirect but should send a standard 403

6. For each functional requirement listed in question 5, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.

7. Is there already an existing RFE upstream or in Red Hat bugzilla?

no

8. Does the customer have any specific timeline dependencies?

no

9. Is the sales team involved in this request and do they have any additional input?

no

10. List any affected packages or components.

11. Would the customer be able to assist in testing this functionality if implemented?

yes

Comment 1 JBoss JIRA Server 2014-10-16 11:50:59 UTC
Pedro Igor <pigor.craveiro> updated the status of jira EAP6-226 to Resolved

Comment 2 Pedro Igor 2014-10-16 14:17:07 UTC
Fixed in upstream. See https://issues.jboss.org/browse/EAP6-226 and https://issues.jboss.org/browse/PLINK-273.

Comment 3 JBoss JIRA Server 2014-10-16 14:36:30 UTC
Pedro Igor <pigor.craveiro> updated the status of jira EAP6-226 to Reopened

Comment 4 Pedro Igor 2014-10-30 20:06:22 UTC
Backported from upstream.

Commit:

https://code.engineering.redhat.com/gerrit/#/c/35784/

Comment 6 Peter Skopek 2014-11-18 11:33:23 UTC
Can we get ACK on this issue, please?

Comment 7 Pedro Igor 2014-11-27 12:43:06 UTC
In order to properly handle AJAX requests, the IdP is now checking the existence of the X-Requested-With header. Usually this header is sent from AJAX libraries such as JQuery.

If the request contains this header with value XMLHttpRequest, the IdP will respond with a 403 instead of the login page.

Comment 8 Ondrej Kotek 2014-11-27 13:51:27 UTC
Verified for JBoss EAP 6.4.0.DR11

Comment 9 JBoss JIRA Server 2015-04-28 15:04:23 UTC
John Doyle <jdoyle> updated the status of jira EAP6-226 to Closed

Comment 10 Lionel Orellana 2015-06-10 04:53:14 UTC
I think the original intentation was to make this configurable. Is that the case? Can I disable this new behaviour?

We use an AJAX request to detect if the unauthenticated user is inside our network or not. Based on that we handle authentication differently. That doesn't work anymore with this change.


Note You need to log in before you can comment on or make changes to this bug.