Basically I want a lightweight CalDav server proxy, which passes the username, password and calendar name to a script and it will respond with either invalid user/pass, no such calendar or return the calendar.
The CalDav server would then return the appropriate response back to the server.
I will only have the calendars of the users stored locally on the server for caching purposes as I don't directly access to the users calendars. My script will try to login to an external site (out of my control in any way) and fetch the calendar by crawling the site.
If possible I would prefer if the server has wsgi support for communicating with my script.
I think your best bet here is to use sabre/dav and write a custom backend for it. As an example, at a company I used to work for I wrote a MongoDB backend for SabreDAV as well as getting the list of calendars from the system it was connected to. This is very similar to your use case, therefore check out this repository. You can find the backend implementation here and will need a lot of the other code to make the calendar listings work.
I would advise to do some caching and not scrape the remote site on each request, since caldav in connection with webdav-sync will want to provide updates since the last time the client synchronized, and that will be harder to do if you are scraping in the moment.
Related
I am trying to make a desktop application with Twitch API and Google API.
Since this application requires Twitch user permission, a user needs to authorize my application through twitch's OAuth and I think there's no way to omit this process.
Now, I want to add some functionalities from Goole APIs, for instance TTS.
My application will be installed and run on user's local machine,
it cannot store API key or credential information safely.
I think I have three options:
Add Google OAuth: This is most safe way, I think, but I don't think I can convince users to authorize another Google account even though they already authorized their Twitch account.
Make a kind of proxy server which verifies request for Google API using twitch authentication information and relays request to/response from Google API. This seems feasible but it requires additional payment to running server for sending data from Google API. I already have to pay for TTS service, another payment for proxy server which sends binary data frequently would be a financial burden for me.
Make a server to acquire API key for Google API. This also requires additional server, but it does not involve lots of traffic because application will access Google API directly once API key acquired. However, I concern that the API key may be easily stolen using monitoring tool such as wireshark.
Which method should I use here, and how can I improve it?
Or, is there better way for this case?
I have a requirement where I have to schedule a console application, which fetches certain records from database and calls an ASP.NET web API. Could someone help me with how to restrict the web API to not get called from anywhere else?
Please help me with any useful links, tips, or steps to follow.
There are a few ways you can lock down access to your application for an rpc call.
You can restrict access via IP with IP filtering.
If you're using windows authentication, you can grant permission to specific AD User or Groups in your web config file.
If you're using forms authentication and basically just need to make an RPC call, you can create an endpoint for your console app which accepts a username/password parameter (using https, of course).
If your setup is more advanced, you can use tokens and ASPNET Identity to limit access.
These are just a few ideas. Basically just google ASPNET security and you'll get a ton of ideas.
I'm having a few problems trying to decide what would be the best solution for something I'm trying to build.
In the applications simplest form, I have a front end server which allows users to upload files which become associated with their account, for example a video or image. The upload file form posts the upload request to the front end server, which then uses a reverse proxy to pass the request directly along to a storage server's API (https://www.example.com/users/username/upload).
What I'm currently stuck on, is trying to work out what the best way to verify that the request being received at the storage servers API is actually being sent from the reverse proxy from the front end server, as opposed to somebody just sending a direct post request to the storage server's API endpoint.
Any suggestions would be really appreciated!
There are multiple ways to do it:
you can use a API Gateway (e.g. APIGEE, AWS AI Gateway etc). Gateway can do request origin validation.
You can let front end app to use OAuth (for storage server) and use
that to get authenticated/authorized at storage server
You can do IP whitelisting between servers & allow a restricted set of IPs in source
You can use MASSL (Mutual Authenthicated SSL) b/w servers to make sure only clients which are verified access your API (may be not for your problem directly but can be used with combination)
These are the simple options if you don't need a complicated or more expensive solution.
I am using Backendless.com as a BAAS for my application. I have some custom logic running on their servers which need to make an HTTP request to the Google Places API.
I'm trying to generate an API key for the Backendless.com server to run this request but i'm not sure what API key I need to generate. The Google developer console gives me 4 options. Server Key, Browser Key, Android Key, & iOS Key.
Server key seems to be the one I want to use... but I need to provide it with some IP addresses... I don't know where or how to find those! The console states that they are optional, but it seems insecure to not add the server IP address. What are the risks? Where can I find Backendless.com app server IP's?
Server key is what you want. Restricting access is a good additional security step to take, it is not however required. They basically make it so that if someone manages to steal your API Key, they can't use it from IPs that are not whitelisted. You will have to ask backendless.com if they have a finite list of IPs they can gurentee your requests will come from.
I have developed a web app that does its own user authentication and session management. I keep some data in Elasticsearch and now want to access it with Kibana.
Elasticsearch offers a RESTful web API without any authentication and Kibana is a purely browser side Javascript application that accesses Elasticsearch by direct AJAX calls. That is, there is no "Kibana server", just static HTML and Javascript.
My question is: How do I best implement common user sign on between the existing web app and Elasticsearch?
I am interested in specific Elasticsearch/Kibana solutions, but also in generic designs for single sign on to web apps and the external web APIs they use.
It seems the recommended way to secure Elasticsearch/Kibana is to have an Apache or Nginx reverse proxy in front that does SSL termination and user authentication (Basic auth). However, this doesn't play too well with the HTML form user authentication in my existing web app. Ideally I would like the user to sign on using the web app, and then be allowed direct access to the Elasticsearch API as well.
Solutions I've thought of so far:
Proxy everything in the web app: Have all calls go to the web app (server) which does the authentication, and have the web app issue the same request to the Elasticsearch web API and forward the response back to the browser.
Have the web app (server) store session info that Apache or Nginx somehow can look up and use to authorize access to the reverse proxy.
Ditch web app sign on and use basic auth for everything.
Note that this is a single installation, so I don't really need any federated SSO solutions.
My feeling is that the proxy within web app (#1) is a common generic solution, but it seems a bit heavyweight to have everything pass through the possibly slow web app, considering that Kibana uses the Elasticsearch API directly.
I haven't found an out of the box solution designed for the proxy authentication setup (#2). My idea is to have the web app store session info in memcache or the like and use some facility in the web server (Apache or Nginx) to look up the session based on a cookie and allow proxy access if authenticated.
The issue seems similar to serving static files directly using the web server (Apache or Nginx) while authenticating using a slow web app. Recommendations I've found for that are however very specific to that issue, like X-Sendfile.
You could use a sessionToken. This is a quite generic solution. Let me explain this. When the user logs in, you store a random string an pass him back to him. Each time the user tries to interact with your api you ask for the session Token you gave him. If it matches, you provide the service he is asking for, else, you just ignore his call. You should make session token expire in a certain interval of time and make a new one each time the user logs back in.
Hope this helps you.