I have coded a C# MVC5 Internet application and I have a Web API 2 web service that returns JSON data. I am retrieving this JSON data in an android application.
How can I add a feature to the web service such that only my android application can retrieve the JSON data? I am wanting to do this so that other web users cannot hammer the url and the web service will not send my data to unwanted applications and/or users.
Is this possible? If so, how should I do this?
Thanks in advance.
You have various ways to achieve this in fact.
For example, you can store a key in your android application and use send this key together with the request to your WebAPI. Your webAPI will than check if they key is valid and if it is, it will return the JSon.
However, there's no way to ensure that nobody else can request and get your data. For example by reverse engineering your android application and extracting the key, or by monitoring the network traffic and find the key in there.
You need to understand that there isn't anthing that guarantuees you 100% security.
See it as the following:
You have an open door right now, you can close it little by little, but closing and locking down is not possible. There will always be gap. A house also can't by made burglar proof, but you can make it very hard for a buglar to enter.
Go to this link Web Api. I have used the individual authentication for my web api. When you will register the user the response you will get is access token and use that access token as Authentication header in your ajax call if you are using Jquery ajax to call your Web Api. Refer this The OAuth 2.0 Authorization Framework. Hope this help you.
Are you looking for something like this?
http://httpd.apache.org/docs/2.2/howto/access.html
If you have other web server, there should be appropriate means to support such.
Related
I have a c#-based program that can send messages and files to our SlackWorkspace via my SlackApp (I'm using HttpClient to communicate with Slack).
Now, to distribute this program in my workspace and to make it so that every user will have his own identity, it says that I have to use OAuth and create verification-tokens, specific for each user.
It says in the Slack-documentation I have to use a redirect-URL (as per docs) to my own server.
We have a server that I potentially could use for this. But I have never done anything like this before and I am unclear on what "answer" I have to provide from our server. I thought the verification-process would be handled by Slack.
Anyone has an idea on how to approach this?
And before anyone asks - yes we need to install it for everyone and make them identifiable as themselves. We can't use the "SlackApp" as user. :)
I would be very grateful for code examples(in c#) and explanations on how this whole redirect-thing is working.
Slack uses the standard Oauth 2.0 protocol to authenticate apps, similar to Google and Facebook.
So the "verification-process" is indeed mostly handled by Slack (as outlined here), but your Slack app needs to initiate it and handle the responses properly. Also its a multi-step process and includes the user having to login into Slack with their credentials. This why you need a web app to handle the whole process.
To enable a Slack app to generate tokens via Oauth a web app is needed:
can be reached from the Internet
able to handle HTTP requests like a web server
has persistent storage for the newly generated tokens
This is probably easier to implement with ASP.NET Web Pages, which can utilize many functions from an existing web server.
But for this answer, lets look on an implementation in .NET Core. For that we need to create our own web server and some rudimentary session handling. Main concepts include:
HttpListener class for providing fundamental ability to listen and respond to HTTP requests
Handle multiple requests in parallel
Cookies / Session handling
MD5 hashes
The details go a bit beyond the scope of one answer. But I am happy to share a working example implementation on this GitHubGist.
Btw: For the local development of such a web app its recommend to use a VPN tunnel like ngrok, that allows one to expose a local machine securely to the Internet and Slack.
I have an existing MVC application that I inherited from someone else.
I am now trying to take some of the API calls from the old application and move them into a new application.
The problem is, when the MVC application tries to call the API calls in the new application, it gets a 401.2 (unauthorised) response.
I have read that 401.2 means that the front end and the back end are using different authentication protocols, which would make sense to me.
Here is a snip of the response headers for the account call in the new application:
and here is a snip of the same response headers when calling the same API from the old application:
This looks to me like they are using different protocols - am I correct? The main difference seems to be the 'WWW-Authenticate:Negotiate' on the failed request - but I do not know how I can fix this?
If so, can anyone advise what I need to change in my MVC project to make it use the Auth type of the first project?
Both aps use the same database if that is any help?
I know this question is a bit vague, but I have no idea where to look to fix this.
Any help would be greatly appreciated...
You would need a Single Sign-on to maintain your credentials through different apps, you could:
Use Identity Server 4 or Identity Server 3 To generate token credentials for you WEB API Projects.
MVC
JS
User Forms authentication on your mvc Projects:
Example
Use cookie based Authorization:
Cookie authorization with OWIN
I recommend Using Identity Server.
I am trying to develop a single page application.
I have built a RESTful web service using ASP.NET Web API. I have implemented authentication using OAuth 2.0 and Bearer access tokens.
This web service uses memcached and HTTP cache headers (Cache-Control and ETag) for caching the resources and responses.
Now, I really like ASP.NET MVC technology and maybe that love is making me use it when I shouldn't.
I'm thinking of builidng an MVC intermediate server between my JavaScript application and my Web service.
The MVC site would redirect (or delegate) its requests, to the Web Service.
I see many advantages using this approach:
I can store my consumer key (used for authentication) in a secure location, as opposed to storing it in the JavaScript application directly.
I can provide cookies to my JavaScript application, something that my REST web service does not support (because I think it ruins the whole "stateless" and "Pure HTTP" concept.
It would be very easy for me to provide globalization (localization) to my views. I really like ASP.NET MVC globalization framework and I would not know how to add this feature if I plan to create a standalone site.
I can encrypt my access token cookie, and decrypt it on the server, forcing my user to use my MVC proxy to access the web service, as he will not know his access token.
Having stated these advantages, would it be worth it to implement this?
Adding a proxy server will made me replicate the HTTP cache logic, and will also end up creating 2 requests (Client -> MVC -> Web API) instead of 1 (Client -> Web API).
What is the best approach?
It looks like you've built a good RESTful web service, but need to address Auth and Globalization:
Auth
Having this kind of proxy or support cookie authentication on the Web API will make you vulnerable to CSRF attacks, so you would also need to implement Synchronizer Token Pattern or some other technique to prevent this. However you should only use this approach if you have no other options, but you have!
Assuming javascript application requires user to enter credentials, there are different ways to deal with auth for it:
OAuth2 Resource Owner Password Credentials Grant
JSON Web Tokens - see accompanying website and a specification
Both ways provide your JS app with an encrypted token that it should pass with each call to protected API. Your application would need to keep this token in a local storage and refresh it when token expires.
Globalization
Even having most of the things on MVC side, eventually you would still require Web API to deliver translated content. So I'm not sure what are the requirements here, but generally speaking you should be able to get your translated resources on Web API the same way. See here for example.
For the HTML part - leave it to ASP.NET MVC, no need to put every label translation into API.
Another points to consider
Performance - ASP.NET MVC is good, but it's not a proxy solution and it's simply not intended to build things like that
Do you really need an HTTP API?
Don't forget that transferring data over HTTP is another point of overhead, and it becomes especially useless if you proxy it with and MVC.
At the end of the day - why would you build an API if you are hiding it from your own application?
My answer is: don't hide it - make full use of it!
I'm building a complex, public web service in WCF that send email to a specific address, similar to a contact form but with some features.
With jQuery I get the data from the textbox and with Ajax and json I send to the web service the strings to proceed at the send.
Now, is there a good way to make it secure?
I mean.. the service is public so someone can have access to it and starting to spam on this address. Can I restrict the users to use the web service only from the correct web site?
Thanks.
IF the WCF service is hosted in the IIS you can allow calls only from a specific IP address, look at the directory security settings under IIS.
By far the simplest way is to have your web service require some type of access key in order to run the operation.
Something simple like a base64 encoded GUID would work. It doesn't even have to change. Just add a parameter called "AccessKey" or something similar. Have your app pass that and let the service validate that it is good.
Another idea is to have the web service check the http headers to see if it came from the page you authorized to use it.
Neither of those are perfect. The first one means that your "key" will be inside the html you send to the client. The second one can be spoofed.
Personally, I'd probably not bother at this level and just log what the service is doing. If the traffic counts to the service start to exceed what you think it ought to be, then I'd investigate ways to mitigate it. Most likely, given that it's a service you won't see any issues.
i could not find any idea of how to implement API over the SharePoint(MOSS) framework.
Could anyone give me a tip please?
What i want to do is create a client application to communicate with the SharePoint.
wanting to implement something like following.
Client send post request to API implemented on SharePoint, API receive a request and do the authentication and create a login cookie.
Client keep communicating with API(with the login cookie), request necessary information and API returns it.
I could not find anyway to hook a program...
Is there anyway to hook a program or implement own authentication mechanism before SharePoint's own authentication is called?
Any alternative approach will be grateful.
Thank you in advance.
Taiga
It sounds like you need the Web Services that ship as part of SharePoint. There is no need to re-invent the wheel by creating your own API.
If your own application runs on a machine with a local SharePoint installation then you can program against the SharePoint Object Model directly. Otherwise use the Web Services interface.
More on Google.
Here you find a fluent API for the SharePoint. FluentSP implements a modern fluent interface around the classic SharePoint 2010 API:
http://www.parago.de/2011/09/fluentsp-the-fluent-sharepoint-api/