Remove Additional Parameter from post logout URL - identity

When the user clicked on the logout button after successful logout user redirects back to callbackurl with additional query parameters.
You can see below the URL return
https://localhost:9443/?sp={spname}&tenantDomain=carbon.super
Can anyone please help me with how we can remove these two sp and tenantDomain parameters?
I found the below article, also there are these two additional parameters.
https://piraveenaparalogarajah.medium.com/rp-initiated-logout-with-wso2-identity-server-b1fde28c4d80
Can search the below text in the article for reference.
Redirect to post_logout_redirect_uri

This seems to be introduced with the fix done for https://github.com/wso2/product-is/issues/3266. It has added the service provider name and tenant domain as query parameters for the success flow as well in addition to the failure flows.
Unfortunately, there is no way to configure this. But you may report this at https://github.com/wso2/product-is/issues and the team will decide whether this needs to be fixed.

This issue is reported for IS 5.10.0:https://github.com/wso2/product-is/issues/12723

Related

Add additional validation for logins using LexikJWTAuthenticationBundle

I want to add additional validation to allow the login, ie, not just check that the username and password match but do other validations on the user before allowing him to login.
I tried extending JWTTokenAuthenticator but it seems none of its methods are called during the login.
I thought of using a custom "AuthenticationSuccessHandler" but I'm not sure if this is the place I should do this and how could I report from there that the "login" is actually invalid.
Where should I put this logic?
I end up replacing the "login_form" authentication shown on the LexikJWTAuthenticationBundle bundle documentation for a custom guard authentication just for the login, i.e. different than the guard authentication used to validate the JWT tokens.
In the past, I had a similar requirement. Within the alternatives I chose to implement a custom user provider. Symfony documentation on custom user provider creation is more than enough to accomplish the task. Moreover, "Configuring the user provider" section of the LexikJwt documentation explains how to configure lexik_jwt accordingly.

External authentication doesn't work in Datazen

I set the authentication in control panel as below:
and i call the viewer by this code:
$.ajax({url: 'http://192.168.17.31/viewer',
headers: {'thisistheheadername':'thisistheheadername'},
type : 'GET'
});
but still request redirects to login page:
http://192.168.17.31/viewer/login
I'm not totally sure what you're trying to do. I've never seen AJAX used with Datazen like this, although I suppose I can understand how it might work. Of course, it won't be secure, because the browser could always indicate who the user should be--there's no checking.
The top chart in this answer might help you. But beyond that, what tells you it's sending to the login page? Where are you trying to display the results?
The two things I would check on outside of those, though, are:
Your header is not correct, unless you've got a user named "thisistheheadername" as well. You should be passing a username through that value. I don't recall specifically, but it could send you to the login page if it doesn't recognize the username.
Are you sure external authentication is enabled? I would check in the "Configuration" section on the server to ensure it isn't still "default." The core service must be stopped before changes are persisted.

$_GET values being stripped by returnUrl (on an authentication server not under my control)

Issue:
An authentication server (not under my control) is stripping get values after the first from the returnUrl. Is there any way to work around this? (Or around the larger problem as a whole?)
e.g. http://authentication.corporate.com?returnUrl=http://localserver/addcomment.php?FirstName=Sally&SecondName=Sparrow redirects as http://authentication.corporate.com?returnUrl=http://localserver/addcomment.php?FirstName=Sally, stripping any subsequent $_GET values.
(I am led to believe through my research that the stripping of the $_GET values may be an issue with what the authentication server is doing, but I have no way of getting access to it. If this is the case, is there a workaround? If this is not the case, what am I doing wrong?)
Context:
I am writing part of a web application which is to allow users to add comments to documents. The web application must retrieve the user's (correct) corporate username, first name and last name.
I am updating a previous version of this web application which allowed users to add comments in a two-step process.
Step 1 After clicking an 'Add Comment' hyperlink, the user is authenticated and a returnUrl value directs them to a page where they may add their comment. http://authentication.corporate.com?returnUrl=http://localserver/addcomment.php
Step 2 In addcomment.php $_POST values have been retrieved (and confirmed as correct) from the authentication server. The user may then enter their comments in a textarea and submit them via action=post to a final page which inserts the comment and user information into a database.
I would like to reduce this to a one-step process where the user may type in a comment on the main page. The way I am attempting to do this is by passing the comment as a $_GET value to be returned via the authentication server. e.g. http://authentication.corporate.com?returnUrl=http://localserver/addcomment.php?FirstName=Sally&SecondName=Sparrow along with the $_POST values.

Oracle APEX - HTML Links Breaks Session and Requires New Login

Ok so here is what is happening:
I have a client that I am building an application for. My client has a flowchart that they would like posted on the front page of their application. Check. My client then wants this flowchart to be set up as an image map so that a user could click one of the boxes in this flowchart and be taken to a report in another part of the application. Check.
All of that is elementary and, in a technical sense, works. The issue is, and it is an issue I have encountered before with APEX, is that every time a user clicks one of these links it takes them to the login screen. It seems that linking directly to a page's URL breaks the session and requires you to login again, even if you are linking from one page in the application to another in the same application.
I have played with all of the authentication settings in a hopes of fixing this and tried to determine what is breaking the session exactly but with no luck.
Has anyone else had this problem and could share their method for fixing it? I really cant have users logging in every time they click a link and I also cannot simply remove the authentication on the pages. Thanks in advance.
You should pass on the session id in your links. If you don't, then apex will see this as a new session. You can tell from the url: take note of the session id in your url when you are on your image map. When you select an application, take another look at the session id part in the url. If they are different, then you are starting a new session each time.
/apex/f?p=190:90:1674713700462259:::::
190 -> application id
90 -> page id
1674713700462259 -> Session id
To pass on the session, it depends where you construct your links.
In PLSQL, you can find it through :SESSION or :APP_SESSION
For example, in a plsql dynamic region: htp.p('the session id is '||:SESSION);
In javascript code you can use $v("pInstance") to retrieve the value dynamically, or use &APP_SESSION. which will have the value substituted at runtime.
Small example:
function printsome(){
var d = $("<div></div>");
d.text('&APP_SESSION. = ' + $v("pInstance"));
$("body").append(d);
};
So you probably just need to alter the construction of your link somewhat to include the session!
I was assuming the binding variables will do the job. But they were helpless.
Best way is to pass the current session id to an item then use the item value in the link.
f?p=&APP_ID.:32:&P31_SESSION.:::P32_CUSTOMER_ID:#CUSTOMER_ID#

Retaining HTTP POST data when a request is interrupted by a login page

Say a user is browsing a website, and then performs some action which changes the database (let's say they add a comment). When the request to actually add the comment comes in, however, we find we need to force them to login before they can continue.
Assume the login page asks for a username and password, and redirects the user back to the URL they were going to when the login was required. That redirect works find for a URL with only GET parameters, but if the request originally contained some HTTP POST data, that is now lost.
Can anyone recommend a way to handle this scenario when HTTP POST data is involved?
Obviously, if necessary, the login page could dynamically generate a form with all the POST parameters to pass them along (though that seems messy), but even then, I don't know of any way for the login page to redirect the user on to their intended page while keeping the POST data in the request.
Edit : One extra constraint I should have made clear - Imagine we don't know if a login will be required until the user submits their comment. For example, their cookie might have expired between when they loaded the form and actually submitted the comment.
This is one good place where Ajax techniques might be helpful. When the user clicks the submit button, show the login dialog on client side and validate with the server before you actually submit the page.
Another way I can think of is showing or hiding the login controls in a DIV tag dynamically in the main page itself.
You might want to investigate why Django removed this feature before implementing it yourself. It doesn't seem like a Django specific problem, but rather yet another cross site forgery attack.
2 choices:
Write out the messy form from the login page, and JavaScript form.submit() it to the page.
Have the login page itself POST to the requesting page (with the previous values), and have that page's controller perform the login verification. Roll this into whatever logic you already have for detecting the not logged in user (frameworks vary on how they do this). In pseudo-MVC:
CommentController {
void AddComment() {
if (!Request.User.IsAuthenticated && !AuthenticateUser()) {
return;
}
// add comment to database
}
bool AuthenticateUser() {
if (Request.Form["username"] == "") {
// show login page
foreach (Key key in Request.Form) {
// copy form values
ViewData.Form.Add("hidden", key, Request.Form[key]);
}
ViewData.Form.Action = Request.Url;
ShowLoginView();
return false;
} else {
// validate login
return TryLogin(Request.Form["username"], Request.Form["password"]);
}
}
}
Just store all the necessary data from the POST in the session until after the login process is completed. Or have some sort of temp table in the db to store in and then retrieve it. Obviously this is pseudo-code but:
if ( !loggedIn ) {
StorePostInSession();
ShowLoginForm();
}
if ( postIsStored ) {
RetrievePostFromSession();
}
Or something along those lines.
Collect the data on the page they submitted it, and store it in your backend (database?) while they go off through the login sequence, hide a transaction id or similar on the page with the login form. When they're done, return them to the page they asked for by looking it up using the transaction id on the backend, and dump all the data they posted into the form for previewing again, or just run whatever code that page would run.
Note that many systems, eg blogs, get around this by having login fields in the same form as the one for posting comments, if the user needs to be logged in to comment and isn't yet.
I know it says language-agnostic, but why not take advantage of the conventions provided by the server-side language you are using? If it were Java, the data could persist by setting a Request attribute. You would use a controller to process the form, detect the login, and then forward through. If the attributes are set, then just prepopulate the form with that data?
Edit: You could also use a Session as pointed out, but I'm pretty sure if you use a forward in Java back to the login page, that the Request attribute will persist.