I've created an api using .net core 2 and C#. I'm wondering if there's anyway to find out information about the computer or user that called the api. This is an internally used api so ideally I'd get the Windows user of where the api call came from, but if there's anything I can find out (like an IP address) I'd like to know how. If this isn't possible at all, I'd like to know so I can stop looking for a solution.
No, it's not possible. The server knows only what the client chooses to tell it, typically via request headers. However, the client can also lie, or "spoof" these headers. So, while something like User-Agent may look like it might give you some info about at least the OS/browser, all of that could be completely fabricated.
Matters are even worse with an API, as clients are typically thin, and the actual programmer or whatever connecting to your API must make a conscious decision to provide you with some particular bit of information, which most won't. A web browser typically sends certain standard things without user intervention, but even then users can change or alter what is sent.
Related
Over the years I have written many apps for myself and for customers using VB.NET, most of these were standalone apps which worked on workstations and servers and didn't involve much if anything to do with networking, client/server or a backend.
I want to evolve and learn more, and specifically am interested in creating a "backend" for some of my apps so that the data from the client app, whether it be error information or custom data for a client can be sent from the "client" to whatever is the best option for the "backend". I would then store the received data in a database I assume and then have ability to view it, and parse the data to show specific results etc
This is a new area to me but one I want to learn more about, so I am hoping that others who have this knowledge / experience can give me some pointers as to the best route to take etc, especially covering the points below and anything else you think I need to know but have missed
What to use for the "backend"? I prefer to have it in the cloud rather than having my own server, so do I use something like Azure? if so what? or do I sign up for hosting with a company which provided ASP and .NET Core hosting and create something there? if so what would I use?
What are the best methods for sending data from a to b - I notice most services I currently use for my apps e.g. for sending mail or error reports etc often use JSON? is that best option?
How do I send the data, any built in or suggested frameworks or API's to use to "post / send" information from my client to my backend / remote endpoint?
Hope this all make sense, please ask if not, all comments appreciated, as I say I want to use this both as a way to create / modernize some of my existing apps, but also as a learning exercise to learn areas I don't know and hopefully also make user of newer / evolving technologies and solutions.
Thanks
Basically, I'm looking for the absolute simplest way to add an email (which is effectively a Customer object with no other parameters) to my list of Customers. The use-case is a jQuery-based pop-up email collector that I'm writing because I'm not happy with/don't want to pay for more established solutions.
Everything is working correctly, except I'm stuck on how exactly to authenticate to my Shopify store. Via Javascript I can only perform a few API calls, none of which I need. There are also very complex solutions for creating full-fledged apps for Shopify which are able to do everything, but I think that's overkill for this one API request I need to make.
I know that all I need to do is make a POST request once authenticated per these instructions. What is the best way to do this?
If you want to create user from jQuery you can generate using AJAX POST call in appropriate URL generated using Private App, but be careful before placing authorization details in front end since it will be visible and any one can misuse it.
The better way is to create user using HTTP Post call from some server side language like JAVA or PhP or some language.
Im using basic auth in nginx, no issue there, but i would like to limit the number of distinct locations a user is authenticated,
The end goal is to prevent user sharing access data to website, since the website does real time "monitoring" of some data, i wan't that if the same user/pass combination is used from another ip, that or either both users stop getting data,
or one of them stops getting data.
I don't think that is a good idea, because a user may log in via pc and mobile phone at the same time and has two different ip addresses that way. Also http-auth isn't designed to do what you want it to. It would have to remember the ip-address and make it expire somehow, when the user leaves without logging out. Altogether would it be difficult to guess for how long the session is valid. Another problem is, that most users don't have static IPs and get disconnected by their providers every 24 hours. What happens if that occurs after a valid login?
The most popular method to deal with this kind of problems are session-cookies. These can be described as a one time password and you can use that for as long as you want or until it expires. SessionIDs are usually saved in some kind of database and making those sessions unique would not be a big deal and may therefor be what you want. Luckily the
ngx_http_auth_request_module would allow you to only implement this missing part and would bring you as close as you can get without developing your own nginx-module (see https://www.nginx.com/resources/wiki/modules/ for available modules).
On the other hand: Don't do that. Seriously. If you care for security, do not try to reinvent the wheel and use something, that has already proven. E.g. ngx_http_auth_jwt_module allows you the use of OpenID, which also sets you free from saving sensible user data on your server (because nobody wants to save passwords unless it is absolutely necessary).
Both of these methods require nginx-modules, which may not be installed on your server. If you don't have the permissions to build them, I would suggest to add that to your question, so that others can suggest solutions for non root servers.
If you want to keep it simpler you should also consider to generate download links each and every time and save ip-address and download link address in a database. Delete entries when a user downloads that file and you are done. For that to work you can use the
Content-Disposition: attachment; filename=FILENAME-HTTP-Header, so that your download.php doesn't save a file that called alike.
May be you can also find some kind of javascript to replace ngx_http_auth_jwt_module and use OpenID with http-auth. That can work, because it is possible to do the authentication with ajax as well.
Last but not least: If you still want to do http-auth, also use HTTPS, because your passwords won't be encrypted by this auth-method by default.
What you want to do is unusual so you will need to write a lot of the logic to handle the process.
Your code will need to store a User ID and IP Address pair for each loged in user and validate each attempted log in against this. As the previous answer pointed out, you will need to expire logins etc. Basically, you need to roll a session handler.
This is not impossible or particularly difficult but you need to write it yourself in one of the scripting languages available to Nginx which are either Perl, which is not recommended due to limited ecosystem in Nginx, or Lua, which is highly recommended due to the massive Nginx lua ecosystem (used by Cloudflare for instance).
You will need to compile in the 3rd party Nginx Lua Module and associated modules or just uninstall Nginx and use the Openresty Bundle which already has everything you will need included instead ... including Redis for storage if you need to scale up.
Here are some tools you can use as your building blocks
Openresty Session Library
Openresty Redis Session Library
Openresty Encrypted Session Module
Note that you can implement Openresty stuff directly in Nginx if you wish without having to run Openresty as it is just a convenient bundle of Nginx and useful module.
I have a website that revolves around transactions between two users. Each user needs to agree to the same terms. If I want an API so other websites can implement this into their own website, then I want to make sure that the other websites cannot mess with the process by including more fields in between or things that are irrelevant to my application. Is this possible?
If I was to implement such a thing, I would allow other websites to use tokens/URLs/widgets that would link them to my website. So, for example, website X wants to use my service to agree user A and B on the same terms. Their page will have an embedded form/frame which would be generated from my website and user B will also receive an email with link to my website's page (or a page of website X with a form/frame generated from my server).
Consider how different sites use eBay to enable users to pay. You buy everything on the site but when you are paying, either you are taken to ebay page and come back after payment, or the website has a small form/frame that is directly linked to ebay.
But this is my solution, one way of doing it. Hope this helps.
It depends on how your API is implemented. It takes considerably more work, thought, and engineering to build an API that can literally take any kind of data or to build an API that can take additional, named, key/value pairs as fields.
If you have implemented your API in this manner, then it's quite possible that users of this API could use it to extend functionality or build something slightly different by passing in additional data.
However, if your API is built to where specific values must be passed and these fields are required, then it becomes much more difficult for your API to be used in a manner that differs from what you originally intended.
For example, Google has many different API's for different purposes, and each API has a very specific number of required parameters that a developer must use in order to make a successful HTTP request. While the goal of these API's are to allow developers to extend functionality, they do allow access to only very specific pieces of data.
Lastly, you can use authentication to prevent unauthorized access to your API. The specific implementation details depend largely on the platform you're working with as well as how the API will be used. For instance, if users must login to use services provided by your API, then a form of OAuth may suffice. However, if other servers will consume your API, then the authorization will have to take place in the HTTP headers.
For more information on API best practices, see 7 Rules of Thumb When You Build an API, and a slideshow from a Google Engineer titled How to Design a Good API and Why That Matters.
I have an app that creates a couple of WebView instances and I'd like to have them operate as independently as possible.
At the very least, I don't want them sharing cookies. A quick google search gave me results liking "you can't." I'm hoping someone has a better answer.
The basic answer is "you can't".
After looking at this for a bit, I think it's possible, but extremely complicated. It would involve implementing a resourceLoadDelegate on your WebView that implements -webView:resource:willSendRequest:redirectResponse:fromDataSource: and modifies the request to turn off HTTPShouldHandleCookies and adds any relevant cookies to the request manually. It also has to implement -webView:resource:didReceiveResponse:fromDataSource: to find out about any cookies returned from the server. You can alloc/init your own copy of NSHTTPCookieStorage per-webview and use that to store/retrieve the cookies.
This post sums up what you could do. I'm not sure if it is feasible for you and I feel it wouldn't be a straightforward task, maybe even risky, but it seems to be possible: the author claims iCab does it this way.
I was hoping for a simpler solution too, really. Of course, since Webkit is open source you could just roll out your own version of the framework with changed behavior I guess?
I would assume that cookies would be configured on a service / application level and not for particular instances or processes. Perhaps you could revise your question to find a way to resolve the problem you are having which requires that the instances do not share cookies.
What is the motivation for not sharing cookies between the instances?
If you just need 3 views into the same web resource you could setup some virtual hosts that point to the same data source.
What you can do is take a look at libcurl which can handle cookie stores that don't mix with the URL Loading system wide cookie storage for those requests you want to separate. For me that seems to be a valid and simple solution. If you really need to depend on webview/webkit it might not be.