I had in mind to make a website that pulls data from steam statistics to show how many players are currently playing a specific game. Is this possible or does it have to be an actual api?
If you're planning on this website only ever being a platform that displays the information you're pulling from the Steam API when users access your site, then no, you don't necessarily have to create a public-facing API.
However, if you're creating this application with the idea that other applications are going to programmatically retrieve the data you're displaying on the site, then yes, you should create an API that allows other applications to consume your data.
The best way to do the latter would be to create an independent service that consumes data from the Steam API and transforms it, then makes it available publicly (with authentication if deemed necessary). This API would then be consumed by a client that you create (your website that displays the data) as well as any other application that could make use of the data.
Related
I've read a lot of articles on this subject and they all suggest completely different things that I can't yet structure in my head.
I have one backend app (spring-boot + kotlin). I have nginx and one android (kotlin) mobile app uses backend api and of course Postgres. By the way backend app and postgres are packages in docker containers via docker-compose.
My task is to make the API of my backend service can only be used by this mobile application and no one else. But I also want it to be able to use the API if I have a Web application in the future.
I would be fantastically grateful if you could describe, in a few words, modern technology that could be used to accomplish my task.
For example:
Spring-security: a huge thing that you don't know what to do with, most likely you can use it to solve your problems, but it's overkill. But if you decide to use spring-security, this will help you {...}
...
By the way, I'm not against spring-security, I just really think it's too much for my task. But I'd be happy to hear your opinion.
Your Problem
My task is to make the API of my backend service can only be used by this mobile application and no one else. But I also want it to be able to use the API if I have a Web application in the future.
You have in hands a very hard task to complete. While not impossible it's very hard to accomplish with code written on your own or by trying to leverage security features on your framework of choice.
To understand why it's so hard you first need to understand the difference between who is in the request versus what is doing the request.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
After you understand this idea and it's ingrained in your mindset, you will look into mobile API security with another perspective, and you will be able to see attack surfaces that you never though they could exist.
Possible Solution
I would be fantastically grateful if you could describe, in a few words, modern technology that could be used to accomplish my task.
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
The best approach to solve your problem is to go with a Mobile App Attestation solution suggested in the answer I linked. A Mobile App Attestation needs to be able to work in tandem with your mobile app and backend in order for the backend to have a very high degree of confidence that what is making the request is indeed a genuine version of your mobile app, that hasn't been tampered with statically or at runtime, and it's not under a
MitM Attack
The Manipulator-in-the middle attack (MITM) intercepts a communication between two systems. For example, in an http transaction the target is the TCP connection between client and server. Using different techniques, the attacker splits the original TCP connection into 2 new connections, one between the client and the attacker and the other between the attacker and the server, as shown in figure 1. Once the TCP connection is intercepted, the attacker acts as a proxy, being able to read, insert and modify the data in the intercepted communication.
The MITM attack is very effective because of the nature of the http protocol and data transfer which are all ASCII based. In this way, it’s possible to view and interview within the http protocol and also in the data transferred. So, for example, it’s possible to capture a session cookie reading the http header, but it’s also possible to change an amount of money transaction inside the application context
Be aware that solutions to solve your problem that are specific to the backend or to the mobile app will not be able to achieve a very high degree of confidence in securing your API backend from serving requests not originated from your genuine mobile app, but it's better to have them then nothing.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
The easiest way probably is to define a shared secret on the phone and the backend service.
On the mobile phone, with each request, you send the secret, e.g., as an HTTP header.
On the backend, you need to implement a Filter (e.g., OncePerRequestFilter) that checks the request for the secret and compares it to the value stored in the backend.
I am working with Google Firestore in native mode and CRUD'ing data within it using the "cloud.google.com/go/firestore" api in Go. Access to the data is wide open as long as you know the project id and using the Firestore API on a server. I don't want to try the rules until I figure out how to secure the data from server attacks that. Again, all the API requires is the project id to access the data so I need to lock that down firstly before I move any further. Rules are only for mobile/web clients from what I read and Server side clients completely bypass the rules. Please help. I do not want to use the Firebase API because attackers can still use the Firestore api to access the data.
It's unclear from the limited information in your question but, your Firestore database is not open to anyone with the Project ID.
The service is only accessible to any thing (human|machine) that has valid credentials. Either humans with e.g. Gmail accounts or Service Account key holders.
In either case, only identities that you've explicitly added to the project will be able to access its resources and then only those with the appropriate IAM roles|permissions.
Google provides an elegant facility called Application Default Credentials (ADCs) that simplifies authenticating clients.
I suspect that your code is using ADCs to authenticate you to the project|service.
Access to the data is wide open as long as you know the project id and using the Firestore API on a server.
If that is a concern, consider disallowing all access in the Firebase security rules for your Firestore database.
Also have a look at my answer here to understand why sharing your project ID is not a security concern, and in fact is necessary if you want to allow direct access from client-side devices: Is it safe to expose Firebase apiKey to the public?. If you don't want to allow direct client-side access, closing down the security rules (as they are by default, unless you choose test mode when creating the database) is the way to go.
I have a Teams application (Tab). I am an ISV provider, and provide a multi-tenant application that is installed by customers via Teams App Store in their organizations.
How do I save settings for my application organization-wide for the customers? For example, CustomerA has installed the app and then CustomerB. I want some storage that would be unique for CustomerA and CustomerB and the app, and located in customer's environment. The settings I want to save are not per-user, but per-organization (tenant).
Somewhat similar to "App Data" folder you have in Windows Desktop for example.
Does such a storage exist? Does API for this storage exist?
A tab app is a simply a web application that you render inside of Teams. As a result, what the app does, and where and how it does it, is totally up to you. This includes any data storage you choose to have behind the scenes. For example, your tab could be built in PHP and use MySQL, or built in ASP.Net and use SQL Azure or CosmosDB. It's totally up to you, but you need to implement it yourself, as an ISV.
The important piece to differentiate clients, however, is being aware of the TenantId for each user, so you can look up which client's settings you need from the database. The most simple way to do this is simply the tid property on the Teams tab context. You can read more about that here. Unfortunately, because it's just accessed via Javascript, it's not entirely secure - for a more secure mechanism, you should be creating an Azure Application, and generating jwt tokens that you can authenticate against in your backend. It's a much more complex topic, but hopefully this answer at least gives the background you need. For more info on the security aspects (validating the token etc.), please see this question: How to restrict access to Azure Function to only allow requests from a custom Microsoft Teams App?.
I have a desktop application which uses flat files (some xml and small pictures) as data. I want this data to be available on other PCs which have the desktop application installed and usable by a smartphone client (WP7 at the moment) as well.
The user should have it very easy to synchronize this data. He should be able to use accounts he already possesses (Live-Login, Googlemail, Facebook,...).
I thought about using Azure Blob Storage to save the data in Azure, the Sync Framework to perform the actual synchronization and the Access Control Service to handle authentication.
I have not used any of this technologies before so any advice would be great but I'm searching foremost for errors or shortcomings in this strategy I don't see yet. Is this approach viable at all?
Windows Azure is basically a virtualized datacentre. It is elaborate and complicated and is pitched at corporations who don't want to own their server infrastructure or hardware.
If I understand correctly, what you want is a cloud fileserver, not a whole LAN. Windows SkyDrive fulfils this requirement nicely and offers 25GB of storage per member with no charge for membership.
About Hotmail and Windows Live People often confuse Hotmail and
Windows Live, because when you set up a Hotmail account it uses
Windows Live for authentication and therefore you end up with a
Windows Live account and all the associated facilities, including
SkyDrive. However, it is entirely possible to set up a Windows Live
account using any email address as the username.
If you do this, it is important to be aware that the Windows Live
password associated with a given email address is completely
independent of the password required by the mail server that hosts
mail for the account. This can cause a great deal of user confusion.
For Hotmail (or any other mail server that uses Windows Live for
authentication) they are guaranteed to be the same password.
There is no official Microsoft framework support for SkyDrive. There is an open source project called SkyDriveApiClient, but it only works with the full .NET framework. I tried porting it but the author was a bit of an architecture astronaut, and it is absolutely riddled with [Serializable] which is not available on WP7x.
The WP7 guys have said that the WP7 framework will probably include support for SkyDrive but not in Mango (WP7.1) and given that Microsoft's typical release cycle is 18 months and Mango has yet to hit the streets, I'd say it will be two years before you can count on intrinsic cloud file services for WP7.
Roll-your-own wouldn't be hard, WCF services are dead easy to use from WP7. But that's not really cloud since you have to provide and maintain the server infrastructure yourself. For this reason and given the MS timetable, I have put a great deal of effort into producing my own SkyDrive client for WP7. Core functionality is complete and I am now refactoring, improving robustness and adding performance enhancements like local cacheing of tokens (cookies, essentially). I don't intend to release it; I have a number of apps planned that depend on this functionality and it suits me fine that there is a substantial barrier to competition.
I didn't tell you that to tease you. My point is that I'm so sure SkyDrive is the right answer that I put a lot of work into making it happen.
Cloud file storage is a perfect fit for mobile devices.
Azure is not a good answer for the sort of phone apps individuals want because the data store isn't shared in a way that required indexing or supports high levels of concurrency
I can certainly think of corporate phone apps that would benefit from using SQL Server as storage
Azure can do file services but it represents an ongoing expense. Nobody's going to put up with that when Google and Microsoft both give away web based cloud storage.
I can personally attest that if you're determined, it is possible to use SkyDrive from WP7.
Cloud storage is the only way you're going to get programmatically accessible storage that's shared by your user's mobile device and his computer. One of the things I intend to do that depends on shared storage is write a Silverlight app that lets you prepare map routes with multiple waypoints on a desktop computer and a companion app that uses them on WP7.
The Windows Live team has released what they call support for WP7. They supply a sample project showing you how to instantiate a browser object and load their login pages and manipulate them to log in and use their javascript API to manipulate SkyDrive.
This has one big advantage: browser cookies and cached credentials. The disadvantages are obvious; technical shortcomings notwithstanding the Windows Live team seems to think the only thing people want to do with a phone is tag their photos and fiddle with social media.
I have finished my own libraries. They do not support most of the social media twaddle. I have treated SkyDrive as no more or less than a cloud file system, providing
Authenticate(username, password)
CreateFolder(folderpath[, blocking=false])
Delete(fileOrFolderPath[, blocking=false])
SaveString(filepath, value[, blocking=false])
LoadString(filepath)
I could handle binaries but Convert.ToBase64 makes this unnecessary and strings are convenient for XML. CreateFolder, Delete and SaveString are optionally blocking. LoadString is always blocking because it's a function that returns the loaded string. CreateFolder is recursive so you can create an entire path in one call (eg /folder1/folder2/folder3). Calling CreateFolder on a pre-existing path has no effect, and SaveString uses CreateFolder to ensure the path is valid, making it unnecessary to create a filepath in advance. Authenticate loads the file system (except file content) into memory eliminating server chatter. This is asynchronous and a FileSystemReady event announces when the file system is completely loaded. The model is maintained as you add and remove files and folders.
This was a lot of work and no one reponded to my attempt to make it an open source project so I'm not inclined to give the fruits of my labour away, but provided your plans don't compete with mine I could be persuaded to come to an arrangement.
I am developing a feature in my app where I need to store the state of a particular series of actions between 2 users, just like an ajax based chat service.
The scenario is as follows:
A user can is able to see which other users are online and then challenge one of them. The other user receives the challenge and accepts it. Now both the users are given 5 questions each and the match starts simultaneously for them (almost simultaneously) Then as a user navigates thru the question or solves it, the state is updated on the other user screen as well.
Essentially this is very similar to a chat system like say facebook chat. I am able to see who all are online. I send a chat msg to my friend who can then respond to that and that response is seen on my chat window.
I believe all this can be achieved by using ajax. I can easily make ajax calls to .asmx webservices and retrieve objects for a particular user as Session can be accessed there. However, I am wondering where to maintain state because session is for a particular user and I want my particular object to be accessible for two particular users.
Where do I store the state? Or taking the example of Ajax based chat, where should I store what message User1 entered and when Uer1 entered how is it shown to user2?
I was thinking application object but read it is not recmmended.
What do you recommend for such a thing?
If you're trying to do "near real-time" message passing you might want to take a look at HTTP polling (a.k.a. long polling). I won't use SQL for temporal message passing and short-term state transitions like I've seen in the past. If running on a single web server just keep the state in session or in the ASP.NET Cache. If running on multiple web servers take a look at distributed caches like memcached, Velocity (Win 2008), or NCache. Then serve the cached data to the AJAX requests which are sitting and waiting (because of long-polling). The key design issue is the design of the cache keys (no pun intended), which would need to include the user's ID for user-specific event data.
P.S. There are frameworks for large-scale, near real-time message distribution that solve scaling issues which are hit when hundreds of clients are participating in long-polling at the same time. The broad name for those frameworks are 'Comet', and they are most useful when broadcasting the same messages to many clients.