I'm using MVC4 c# and have incorporated a home grown security token service (STS). The user calls the actual web address, and they're passively redirected to the STS login. When they successfully authenticate they're redirected to where they're supposed to go, which was all urlencoded in the URL on the redirect to the sts.
Upon logout, we call:
this.Session.Abandon();
this.Response.Cache.SetCacheability(HttpCacheability.NoCache);
this.Response.ClearContent();
// expires the claims
FederatedAuthentication.SessionAuthenticationModule.SignOut();
FederatedAuthentication.SessionAuthenticationModule.CookieHandler.Delete();
WSFederationAuthenticationModule authModule = FederatedAuthentication.WSFederationAuthenticationModule
Response.Redirect(WSFederationAuthenticationModule.GetFederationPassiveSignOutUrl(authModule.Issuer, authModule.Realm, null));
Everything seems to work great on the desktop version of our app. The user is back at the STS login page, and the URL shows wlogin1 (and lots of other stuff) and will allow the user to login again without issue. The url is exactly the same as when they first were redirected to the STS. Perfect, and this is what I want.
Now, when on mobile, which by the way uses the exact same domain/controller/Methods, it just uses jQueryMobile and different partial views, the logout appears to work and the user is brought back to the STS login. This time, however, the URL only shows the Domain/Controller/Method that was actually called from the mobile actionLink used for Logout. When the user tries to login again, the login is always unsuccessful because this link isn't appropriate for an sts login.
Thoughts on how to fix this, or what's wrong? Please let me know if you require any clarification. Thanks!
I was able to fix this!!
Looking at the headers for the mobile site it showed:
X-Requested-With: XMLHttpRequest
So, my logout was attempted with ajax and something wasn't working. This was the only difference between the desktop and mobile headers (besides user-agent, obviously). Started poking around this as the issue.
Within one of my mobile-specific scripts I added the following within the mobileinit. BINGO! Wow, what an easy solution for such a confusion problem.
$(document).bind("mobileinit", function (event) {
$.mobile.ajaxEnabled = false;});
Make sure that you correctly load your libraries too!
I have loaded my jquery libraries in this order:
jquery
mobile jquery init file (the stuff above)
jquerymobile
jquery validation
everything else
We're using the following jQuery libraries:
jquery 1.9.1
jquery-ui 1.10.3
jquery.mobile 1.3.1
jquery.validate
Hope this helps others!
Related
I have tried everything. I configured Windows Server 2019 according to Microsoft documentation and I successfully deployed a .NET 5 web application to the IIS.
I can get to the login page. I can even get to the forgot password page and they show themselves fine. However when I try to do any action (send the forgot password link or login to the page) I get a "Bad Request" from the server. I haven't found a way to explain why.
I have tried several, and I mean several things found Googling around but nothing helps. This include disabling https within the .NET Core application, trying to get a detailed error page using the app.UseDeveloperExceptionPage(); instruction inside Startup, etc etc but nothing works. I always receive this page trying to execute any action:
If someone could help or point me into the right direction, I will really, REALLY appreciate it.
Thank you
PD: In case it has anything to do with the problem, the error, at least the two that I can reproduce (because I can't even log in), happens, I think (maybe don't) when redirecting to another page in Microsoft Identity.
EDIT: code was asked by one of you. Thank you.
As you see, there's nothing specific in the forgot password screen for my application. This is scaffold code from Microsoft Identity. I even edited it and just let one line of code inside it, which is the default return code anyway as follow:
public async Task<IActionResult> OnPostAsync()
{
return RedirectToPage("./ForgotPasswordConfirmation");
}
As you can see, there's nothing special with that code. Here's the html that calls it, again, is a scaffold of Microsoft Identity with little to no changes (by little, I mean, maybe some CSS and a new value of view data):
But then again, forgot password page actually shows and seems well in the front end, but immediately I try to enter my email and click enter in this page, (also, just a scaffold of Microsoft Identity):
Nothing happens. I receive the bad request. There's NO magic nor custom code here. Something silly is going on.
EDIT II: YES, locally it works perfectly. The strange behavior happens only when deployed to IIS.
EDIT III: I coded and enabled logging in my .NET Core APP and wrote that to a file, and I think I finally got, at least the error (not the reason yet):
But why?? Cookies are enabled in the server browser without avail, same issue. Someone has a better idea than disabling anti forgery rules to login and forgot password pages?
Thank you
For some reason, when I deployed the first version of my app into IIS, I thought it was a good idea to just browse it from the IIS link. Of course, in a new mounted Windows Server 2019, IE is still the default browser. I connected directly to the IP of my web app via VPN, but used Chrome this time. Guess what? All problems disappeared. Yes, it's a bad idea to try to use a modern framework like .NET Core Identity with IE.
On mid-2022 Google plans to disable third party cookies by default.
My use with 3rd party cookies is through google chrome extension (not for ads service)
I use an Iframe to translate some words on the document.
It looks something like this:
I have a chrome extension that loads an Iframe (In red)
The Iframe (in green) is under my domain x.com (i wish)
Each request that goes from my iframe client to the server is attaching cookie, but from mid-2022 it will be blocked due to chrome policy change and considering that the cookies are 3rd party
I have tried to find solution for this,
All I have found for now is TheTradeDesk Unified ID 2.0 but it will not help me since it's not store value / jwt (its anonymous id)
But could't find any other solution
Any ideas how to handle this?Thanks in advance.
We're also facing something similar, where we noticed if you have your browser configured to block 3rd party cookies, functionality regarding authentication did not work.
This afternoon, we followed a hunch to try and see if the setting to block 3rd party cookies also has an effect on an extension's background page (we're still using manifest v2). And turns out, it is not. So even with 3rd party cookies being blocked, requests made from the extension's background page can still use them.
Not sure if this is by design or a bug. And we still need to investigate how this works with manifest v3.
But hope this helps!
A good news is that Google keeps postponing the timeline for removing 3rd party cookies from Chrome. Right now (Dec 2022) it's planned for the second half of 2024 (https://blog.google/products/chrome/update-testing-privacy-sandbox-web/).
Eventually, we'll need a workaround, though. As #schmkr mentioned, Chrome extension's own code (background page / service worker, and iframes sources from the embedded HTML via chrome://... URLs) are not considered 3rd party. So there are two workarounds:
Pack your iframe app (html/js) as a part of the chrome extension instead of loading it from the external website (x.com in your example).
Keep the iframe app externally sourced, but change its logic. It should not send XHR/Fetch requests any more. Instead it should ask the extension background page / service worker to do that (using the messaging API).
I am scraping website which is made on websphere.
I see that whenever the user logged in, It hits 4 url while reaching to home page.
While in 3rd URL, It has some encrypted value which looks like this
L0lDU0NTSUpKZ2tLQ2xFS0NXXXXXXXXXXXXXXXXXXX..XXXXXXXXXvZD1vbkxvYWQ!
The URL looks like this :
http://example.com/escares/wps/myportal/!ut/p/c1/XXXXXXXXXX/dl2/d1/L0lDU0NTSUpKZ2tLQ2xFS0NXXXXXXXXXXXXXXXXXXX..XXXXXXXXXvZD1vbkxvYWQ!
The problem is, I noticed this only encrypted value changes for every login.
Is there any algorithm in websphere that generates this kind of url ? Or is there any way I can replicate this encrypted value ?
Is there any one who has done crawling/scraping on the websphere site ?
wps/myportal suggests a Websphere web portal login. The 'encrypted' URI you're seeing is most likely a hash to maintain the user login sessions.
The best way to replicate this is to supply your web scraping program with a username and password to access the portal section of the website so it can POST a login while scraping. The website itself will generate the session info. You will need to instruct your scraping application to follow any dynamic URLs that are generated. Usually this is done by following any URLs in the HTML supplied by the server after logging in.
As an example, scrapy can be configured to follow any URLs in target pages when scraping:
https://doc.scrapy.org/en/latest/intro/tutorial.html#following-links
Although you are using your own solution to scrape the contents of the portal for a logged in user, hopefully the logic and progression illustrated in my examples help steer you in the right direction for resolving what appears to be a session/cookie storage issue.
Though Chris has answered the question and it helped me.
This line
Usually this is done by following any URLs in the HTML supplied by the server after logging in.
Just want to update with Node js. The same thing can be acheived by request module and cheerio for parsing the html(which comes in response) in Node JS.
P.S. : In case anyone is looking where i found that dynamic url, I found that in HTML form which came to me in response. It was the action of that form.
I have a website that has a login page. After the login it generates a token for each user (using a cookie).
At some point, after login, the user decides to download my desktop application.
I would like the user to seamlessly login in the desktop application (meaning, I would like the web token to transfer somehow to the downloaded desktop application).
I thought about two options that eventually came up empty:
custom links like http://mywebsite/installer.msi?token=abc. Problem: but I couldn't figure out a way for the MSI to know what was the origin URL it was downloaded from (how do I get that abc string?)
Using uri schema to invoke the installed app from the webpage with the token. Problem: I don't know when the installation was completed. Plus, it involves a user interaction which is something I would like to avoid
My last resort is embedding the token inside the MSI file dynamically for each user (without corrupting it somehow) and reading it inside the installer. But it doesn't seem like a good way to achieve this.
I hope there is another proper way to do it.
Thanks,
Lidan
I am seeing this error from my live server using the Instagram API.
{
"Error":true,
"message":"Matching code was not found or was already used."
}
I have read a few suggestion on here to clear cache but that isn't fixing the issue. I am also unable to submit a support ticket directly on the Instagram site as I am receiving an error message while attempting to submit a ticket.
There are a bunch of developers complaining about the same issue at https://news.ycombinator.com/item?id=13178789. I don't think unchecking "Disable implicit OAuth" fixes the issue as I have already tried that and it didn't work.
The best thing you can do is to submit a report to instagram using your client id to put some pressure on their side to fix this issue.
I have the same issue, I guess it's from Instagram I reported an issue from my client panel in developer > manage clients > Report issue.
You can do they resolve this issue as soon as possible.
There is definitely a problem with the Instagram OAuth flow. The returned authorization code doesn't seem to work for some reason, it's very likely a network related problem that they need to fix on their end.
My theory is that the authorization code generated is not distributed to all Instagram API servers, and if you happen to hit a bad node then you're out of luck.
However, I recently found a solution that doesn't rely on the authorization code. If you use the client-side authentication then you'll be able to retrieve the access token without ever using the authorization code. It's less secure but works great as a temporary fix.
You simply change response_type=code to response_type=token. The token response type will redirect the user back to your website using this URL structure:
http://your-redirect-uri#access_token=ACCESS-TOKEN
I recommend fetching the access token from the URL client-side using JavaScript, and then passing it to an endpoint on your website. E.g. /callback?accesstoken={accessToken}. This is required because the content in the hash is not passed to the server.
Example:
<script>
if (window.location.hash && window.location.hash.indexOf('#access_token=') !== -1) {
var accessToken = window.location.hash.replace('#access_token=', '');
window.location.href = '/callback?accesstoken=' + accessToken;
}
</script>
The code snippet above is copied and slightly modified from the solution at https://news.ycombinator.com/item?id=13178789
You can read more about Instagram client side authentication on https://www.instagram.com/developer/authentication/ under Client-Side (Implicit) Authentication
I just had the same issue. Not sure why, but for me the code returned from oauth/authorize/? had 2 special characters at the end - "#_". After removing these my code worked.
This is due to security restrictions in place on your Instagram app. You can choose to allow it by unchecking "Disable implicit OAuth" for your Instagram app, under the Security tab.