I'm using HttRequestMessage, and adding a cookie in an IHttpFilter as follows:
public IAsyncOperationWithProgress<HttpResponseMessage, HttpProgress> SendRequestAsync(HttpRequestMessage request)
{
var c = new HttpCookiePairHeaderValue("SSOAutologonCertificate", "true");
request.Headers.Cookie.Add(c);
return InnerFilter.SendRequestAsync(request);
}
Using Fiddler I can see that the cookie is correctly added to the outgoing request. However, the reply is an auto-redirect. When fiddler captures that outgoing request, that cookie is no longer set in the http header - it seems to have been forgotten.
Is this expected behavior? Or a bug? If it is expected behavior, is there anything I can do to alter it?
If, on the other hand, I add the cookie to the Cookie collection on a HttpBaseProtocolFilter object, then everything works as expected, and the cookie is there for every auto-redirect query. Of course, while that will work for now, that totally defeats the purpose of a IHttpFilter. :-) This behavior was observed on a windows store app (running on Windows 10 tech preview).
BTW, I spent some time trying to figure out how to step into the .NET source for the Windows.Web.Http namespace, but nothing seemed to work (I can into other .NET source). Is there a special trick for these windows component files (the module is Windows.Web.winmd).
Thanks in advance!
Related
Keycloak inserts session_state, state and code in url fragment params.. sometimes after successful login these remain on the url...
Or, when alternate routes are clicked in the app, these appear again.
Unnecessarily exposing the internals of keycloak params to users.
Is there some solution to not have these appear or delete them?
e.g. http://localhost:3000/home/#state=e625140e-c4f9-4500-858e-32c80e89f8a9&session_state=445229c3-d7eb-46e9-bfba-3339253dd17e&code=af0abde4-a60d-4f34-a101-8db5c76546b9.445229c3-d7eb-46e9-bfba-3339253dd17e.59915134-a59b-4ffb-878a-d02e7e84f2dd
Update:
with more tests narrowed down the issue to occur when
anything on the keycloak instance is touched. e.g. keycloak.token
any function call of keycloak is invoked... then after that these params get added and removed for every url route thereafter...
e.g. await keycloak.updateToken()
Keycloak Sever and js lib Version : 9.0.2
It is not a Keycloak issue. That's how used login flow works (maybe you need different flow, which will be more suitable for your use case). Your app code (used OIDC/OAuth library) should "clean" URL fragments. Cleaning can be: exchange code for the token (in this particular case), remove URL fragments, clean browser history, etc.
Trying to retrofit an old webforms application.
Got my configuration working so that it's prompting for login and successfully redirecting back to the application. The folks that manage the IP can see the response is generated.
However in the callback to my application the User is null. I'm told if it's configured correctly it should be populated.
We have a custom IHttpModule and that is where I can see getting hit with the call to /Saml2/Acs with the User not populated. I think this may be expected as the handler for that is supposed to populate the User, I think? However the following call (the returnUrl configured in sustainsys.Saml2) still has no User and I don't see any sort of error or anything.
Anyone with experience have an idea how to debug this?
The call to /Saml2/Acs should be taken care of by the Sustainsys.Saml2.HttpModule. It will process the response and then call the SessionAuthenticationModule to set a cookie that preservers the User across calls.
To get some more information about what's happening in the library, you can assign an implementation of ILoggerAdapter to Sustainsys.Saml2.Configuration.Options.FromConfiguration.SPOPtions.Logger to get some logging output from the library.
My issue turned out to be that I had another authentication module loaded before SessionAuthenticationModule and Saml2AuthenticationModule in the web config.
The comment in the example was
Add these modules below any existing. The SessionAuthenticatioModule
must be loaded before the Saml2AuthenticationModule
However in my case with I had another authentication module involved that needed to go last.
I'm new to Fiddler and have run across something that seems strange to me. If I select an entry and then click Replay, I get different behavior from when I drag an entry into the Composer window and click Execute.
Should the different behavior between these two methods of re-making a request be different?
Note: I called the second method "cloning" a request because the Composer window says "You can clone a prior request by dragging and dropping a session from the Web Sessions list)."
What is the "different behavior" specifically?
The two operations you describe should behave the same way unless the server returns a redirect or an authentication challenge, in which case preferences will control whether Fiddler automatically authenticates and/or follows the redirect.
Please feel free to email me (Help > Send Feedback) details and/or screenshots of the difference you see.
Several web application authentication protocols (like WS-Federation and the SAML protocol, i.e., so-called 'passive' protocols, and apparently also ASP.NET Forms authentication, see this StackOverflow question, and AppEngine, see this GWT bug comment) lose the original 'URL fragment', i.e. the part after the #-sign.
What happens is roughly the following: in a clean browser (so no cached info/cookies/login information) I open URL (1) http://example.com/myapp/somepage?some=parameter#somewhere. This makes the browser request (2) http://example.com/myapp/somepage?some=parameter, the server redirects me to my identity provider (including URL (2) in the authentication request), and ultimately I'm redirected back to where I came from, which is URL (2): that is the only URL that the server knows about. But I wanted to go to URL (1), and the URL fragment ('anchor') has been lost along the way, actually in the first step already.
This seems to be a fundamental limitation of these protocols, since the server never sees the URL fragment at all.
I know that it according to specifications that the browser requests (2) from the server, when I navigate to (1), leading to this fragment-losing limitation on the SAML protocol, WS-Federation, etc. My question is: how do I work around this limitation?
The obvious workaround is to avoid URL fragments, as suggested in this answer. However, for our specific web application that is not nice, since we use bookmarkable URL fragments in our single-page GWT application, to make sure that a navigation within our application does not cause the page to reload.
My question: What other workarounds or standard patterns are there for this situation?
(I'm specifically interested in a GWT + SAML protocol solution.)
You basically have two options:
avoid using location.hash (use HTML5's pushState instead, at least on browsers that support it; and/or propose a way to generate permalinks within your app – Google Groups does that)
do the redirection using JavaScript. I.e. instead of sending a redirect from the server, send an empty HTML page with some script that takes the full URL (with the hash) and does the redirection using location.assign() or location.replace(). With a bit of luck (depending on the servers), you'll be redirected to that full URL after authentication.
You can of course do both: if the link is a deep-link into the app, then do the redirect (i.e. assume there's no hash), otherwise send a page with JS to make sure you don't lose any state present in the hash.
And finally the obvious third solution, far from ideal: don't do anything, and try to educate users that when they needed to (re)authenticate then they should re-paste the URL or re-click the link or re-click the bookmark.
According to RFC 1738 anchor tags are not sent by the client to the server, when requesting for a resource.
Anchor tags are used to identify a location within a resource and not a different resource on the server. In order to identify the location in the resource, the client needs to fetch the complete resource from the server, and this process need not involve transfer of information about the fragment (as it does not mean anything to the server).
If you do wish to send the fragment character (#) to the server, then you'll need to encode it in the query string, or the client(browser) will simply ignore that section of the URL when it sends the request to the server.
EDIT:
I don't know any real solution but to work around this issue you need to save your full return URL (with anchor tags) somewhere on the client side, because server don't know anything about anchors. For that you could use SessionStorage (http://www.w3schools.com/html/html5_webstorage.asp) to temporary store ReturnUrl until login process is completed. Please note that it won't be supported on older browsers (like <= IE7).
In that case workaround would look something like this:
<script>
if(typeof(sessionStorage) == 'undefined')
{
sessionStorage = {
getItem: function(){},
setItem: function(){}
};
}
window.onload = function ()
{
var key = 'ReturnUrl';
//try to get last returnUrl with anchors
var returnUrl = sessionStorage.getItem(key);
//if we got something, do the navigation
if(returnUrl !== undefined && returnUrl !== document.URL)
{
//clean it up
sessionStorage.setItem(key, null);
//navigate to last URL
window.location = returnUrl;
}
else
{
//store url
sessionStorage.setItem(key, document.URL);
}
}
</script>
PS. Bear with me if there are some syntax errors because I wrote it down from top of my head and didn't try it.
I'm working on a GWT application.
I wish to debug the client side Java code.
I start up the application from Eclipse in debug mode.
The app starts in the browser with the gwt.codesvr= set correctly.
I can debug at this stage.
The app then redirects to the a different jsp page.
The gwt.codesvr= parameter in the URL is dropped.
The app uses History.newItem("xx") quite a bit (as described in http://code.google.com/webtoolkit/articles/mvp-architecture.html#history)
The problem is that I can't now debug the client side code.. as the
gwt.codesvr= parameter has been dropped from the URL.
When I attempt to add it back in, the app History handling code runs,
and the parametes is immediately dropped again.
I checked this on another PC and the same behaviour occurs.
I checked in Chrome and IE8 and the same..
What is the solution ?
Thanks A million,
Fergal.
History.newItem() keeps the query string intact (in this case, the ?gwt.codesvr=... part), so these calls shouldn't be the problem here.
You say, that the app redirects to a different jsp page. Find out, how it does that - it may use something like Window.Location.replace(newURL). Make sure, that newURL contains the gwt.codesvr=... part in its query string.
If the server performs a redirect itself (e.g. if it redirects after a POST request), then make sure, that the server adds the query string in the redirect URL. (You will probably have to submit your codeserver URL with the POST parameters in this case - because this is a client-side concept, and the server cannot simply guess it.)