I'm having a strange problem in a Silverlight Business Application that calls an external API. I'm sure it's just one line wrong or something. The API has one call that uses digest authentication and I handle that all myself. My code was working before, but then I began a transition to hosting the backend API and this front-end website on Azure and something must have changed. Now, before the request comes back to my code to handle, the browser is popping up a login dialog of its own. If I cancel out of that dialog, it moves on to my code and authenticates successfully.
It seems as if the browser is handling the request, noticing the 401 status code, and attempting to resolve it itself. But I do register the ClientHttp factory for the http:// prefix as suggested, and the request type that is created is a ClientHttpWebRequest. Like I said, this was all working about a week ago using the same authentication code and everything, so I'm sure it's just going to be some setting. But I'm not sure where that could be and I haven't found anyone else with this problem.
Curiously, when I publish the ASP project to an Azure website, it all looks and acts as expected, but the login doesn't even pop up the dialog. It simply doesn't do anything when I click "login." So that part looks like maybe an unhandled exception is being thrown then it's not telling me about it, but I'm not sure why that would be the case on Azure but not IIS Express.
Basically, I just don't want that dialog coming up. I am inclined to assume that the same problem that's causing that is whatever is making the Azure-hosted version not do anything.
I've done a fair bit of searching and found this question, "How can I supress the browser's authentication dialog?" which seems to be the same issue, but as I stated a few times, this was working just last week. I do have full control of the API and this site, so I could alter some things to make it suppress HTTP statuses and simply return a 200 with details in the content as a substitute, but I'd rather avoid that extra layer of complexity if it really is something simple, as I imagine it is.
After some fiddling, it seems the best way to handle this error is simply to use the WebRequest.Credentials property and populate it, rather than forming my Digest authorization header myself. It isn't exactly what I was going for, but it will do for now. I still don't know why this stopped working in the first place. But what fun is programming if everything goes according to plan?
Related
In the new .NET 7.0 framework, things have changed considerably...
This has been asked a gazillion times before and if the .NET Core framework would not break all kinds of backwards compatibility then I would have an easy answer. Too bad a lot of answers are related to .NET 4.9 and older and they just don't work.
So in my minimal Web API I want to do some simple request logging by sending the complete URL as a string to a database. (With some additional information.) So I have the HttpContext class (NOT the HttpContext class) with the Request property of type HttpRequest and it just does not have any method to get the original URL that was requested. Only the various parts which I have to concatenate and hope it resembles the original uri...
So, a useful method like Request.Url is now totally gone and the DisplayUrl helper() isn't providing me everything. It leaves out the QueryString. I need that QueryString also.
And yes, I can concatenate this again to get the value that it originally received and made hidden. It just feels wrong, though. Plus, this method makes the uri suitable to be returned in a header. Again, I want to store it in a database for logging purposes exactly as it originally was!
So now I have to ask something that has been asked a gazillion times before, simply because the latest .NET update breaks things again.
The application I'm working on is a multi-tenant application running on multiple domain names including wildcard subdomains and is used to analyze the amount of traffic I get for new domains that I've registered. The whole API will just generate 404-errorcodes back to the user, but I want the whole URL to get registered to determine if the domain isn't getting any funny requests. (Like hackers trying to access https://owa.example.com/wp-booking.php or https://forum.example.com/default.aspx?g=rsstopic&pg=0&ft=0 or whatever.) I also log the body of the request, the request method, the IP address of the user and the headers that are passed and it cal be used by me to extend a blacklist of users who seem to have malicious intent.
The domains where I use it are often fresh out of quarantine and are just in a wait-state until development starts. (Or until someone takes it over.) Responding with a 404-error should tell users (and hackers) that the site does not exist any more. Most users will be aware that the site is gone so they stop visiting, but various automated (and hacking) tools might still be running so the information tells me what the user is trying to do.
Anyways, I need the full URL with the query string, domain name, protocol and everything else that the client has passed to my server. But .NET 7 is preventing me from access to the original URL which is dumb. And the whole project is basically a single app.Run() statement which always returns a 404 error after logging the request. And yes, slow is fine for this API.
Sigh... Request.Url.AbsoluteUri was such a useful function, but it's gone, making all answers going back 14 years or so obsolete as Request has no Url...
UriHelper.GetDisplayUrl(source) should do the trick:
app.MapGet("test_uri", (HttpContext context) => context.Request.GetDisplayUrl());
Returns http://localhost:5207/test_uri?query=1&test=2 for this url.
So in my minimal Web API I want to do some simple request logging by sending the complete URL as a string to a database.
Minimal APIs support request logging - docs, example. Potentially you can combine it with some logging library which allows writing to database.
Easy question, not sure if there is a solution for this problem.
I made a simple browser with WebView2 in a WPF C# app (I made this to be able to use a shell app while I browse on the url where the webview is). It use the same useragent as edge-chromium and until some months ago I was able to log in to google like in a regular browser.
Now if I try to log in I get a "Not supported browser" error from google.
Of course nothing changed in my application, but google say that it will not support log in from a webview ("browser that: Are embedded in a different application"):
https://support.google.com/accounts/answer/7675428?hl=en-GB
I don't really know if there is any workaround for this. I know that I was logged yesterday (and I think that it was possible thanks to the cache or something like that) so if there is a workaround to log in I should be able to stay log in. I know they suggest to use the google API:
https://developers.google.com/identity/protocols/oauth2/native-app
And I already used that in a Unity3d game to log in to my google drive. But I'm not sure how to set my WebView2 to be logged in when I call that API (I know that I can use the response to make new API call and, for example, upload a file to my google drive, but I don't know how to set my webview to be logged and be able to go to google drive url and be logged in any google app).
My question is if you know how to solve this problem or if you got any idea on how to solve it. Or do you think that's not possible at all?
EDIT.
just find out this is a problem with any webview. like you can see here github.com/MicrosoftEdge/WebView2Feedback/issues/1647 it's a security bullshit of google that, instead of finding a solution, blocked every webview out ther from log in to their services (they could solve the man in the middle problem in many ways like asking for a password app, ask for a more limited webview sandbox window etc... they just blocked everything).
So there is not really any solution for this. Even by using Oauth API you can only log in and wait for the response but you cannot access google like in a regular browser with that, you can only make more API call... that's not what I need.
The only solution that I can think of is to just wait for microsoft or someone else to make a "sandbox environment" that will activate by default in a log in page of google (and that google will allow to log in), and will revert back to the regular webview once it is logged in.
I have a program that opens a web browser control and just displays a web page from our server. They can't navigate around or anything.
The users are not allowed to know the credentials required to login, so after some googling on how to log into a server I found this:
http://user_name:password#URL
This is 'hard coded' into the web browsers code. -It works fine.
HOWEVER: Some smart ass managed to grab the credentials by using WireShark which tracks all the packets sent from your machine.
Is there a way I can encrypt this so the users cannot find out?
I've tried other things like using POST but with the way the page was setup, it was proving extremely difficult to get working. -(Its an SSRS Report Manager webpage)
I forgot to include a link to this question: How to encrypt/decrypt the url in C#
^I cannot use this answer as I myself am not allowed to change any of the server setup!
Sorry if this is an awful question, I've tried searching around for the past few days but can't find anything that works.
Perhaps you could work around your issue with a layer of indirection - for example, you could create a simple MVC website that doesn't require any authentication (or indeed, requires some authentication that you fully control) and it is this site that actually makes the request to the SSRS page.
That way you can have full control over how you send authentication, and you need never worry about someone ever getting access to the actual SSRS system. Now if your solution requires the webpage to be interactive then I'm not sure this will work for you, but if it's just a static report, it might be the way to go.
i.e. your flow from the app would be
User logs into your app (or use Windows credentials, etc)
User clicks to request the SSRS page
Your app makes an HTTP request to your MVC application
Your MVC application makes the "real" HTTP request to SSRS (eg via HttpClient, etc) and dumps the result back to the caller (for example,it could write the SSRS response via #HTML.Raw in an MVC View) The credentials for SSRS will therefore never be sent by your app, so you don't need to worry about that problem any more...
Just a thought.
Incidentally, you could take a look here for the various options that SSRS allows for authentication; you may find some method that suits (for e.g Custom authentication) - I know you mentioned you can't change anything on the server so I'm just including it for posterity.
I'm having an interesting problem with FormsAuthentication on a client project I'm trying to assist with. Here's the problem:
The domain of web app was changed from .companyA.com to .companyB.com and I set up an IIS redirect to send anyone attempting to go to .companyA.com to .companyB.com. That works just fine.
Now I can't log in to the site. I did some digging and found out that there are authCookies being defined in the web.config, so I changed the the authCookie domains to match .companyB.com. I was still not able to log in.
I did some more digging and found that there was a SQL Reporting server set up. I changed the domain in the config files of the reporting server to match .companyB.com. Still can't log in.
For general purpose troubleshooting of this type of issue is there anywhere else I could look? I've just been put on this as a firefight so I've limited domain knowledge and can't open the solution in VS because the only VS they have available is too old for the solution.
EDIT: OK, after further digging, I found out that the user isn't authenticating wasn't the main issue. There was a problem with connecting to the reporting service DB and the exception was being swallowed up. Thankfully it showed up in the event viewer. Unfortunately this still leaves me with problems, I can't figure out why SQL won't authenticate me anymore and how changing domain names could possibly lead to that.
Debugging is really simple. Just get any http debugger (Fiddler will do) and run your application. You will see a list of requests. Just pay attention to the response which sets the auth cookie and then what happens in consecutive requests.
You will probably see that the cookie is set but is missing futher on. This could be because the cookie is issued for domain A (you will see the cookie's domain in the debugger) and the browser is not delivering it to the domain B (which the browser is supposed to do; it will never carry cookies to other domains).
Anyway, an http debugger will be a great help here.
What is your best solution for pulling out an exception occurring on a user computer?
For example I send automatically a email when an exception is thrown which body contains the call stack.
Have you experience other quick way to handle user bug?
Unless this is a corporate app, be sure to ask the user if they want to submit anything first.
Then, generally I would recommend submitting it via web service. Better to leverage the end-user's existing proxy settings if any.
ELMAH is a good tool for logging exceptions in ASP.NET websites - it can log the exception to a local database as well as emailing it.
"Once ELMAH has been dropped into a
running web application and configured
appropriately, you get the following
facilities without changing a single
line of your code: Logging of nearly
all unhandled exceptions.
A web page to remotely view the entire log of recoded exceptions.
A web page to remotely view the full details of any one logged
exception.
In many cases, you can review the original yellow screen of death that
ASP.NET generated for a given
exception, even with customErrors
mode turned off.
An e-mail notification of each error at the time it occurs. An
RSS feed of the last 15 errors from
the log."
BugzScout with FogBugz worked wonders for me. An API to your bug database in general is the way to go.
With respect to emailing it, you can simulate some of the features of a bug tracking database but it's not as good as the real thing. If you keep with the email option, be sure to send them to a generic bugs#companyX.com email instead of a personal so they can be routed to a different person quickly if necessary.