Basecamp uses HTTP authentication for its RSS feeds but this means that Google Reader, Bloglines and Firefox/Safari RSS don't work.
Is it possible to secure an RSS feed but still allow access from these popular readers?
Only possible solution I would think is use some randomly generated token inside URL to your feed. InfoQ works this way (with personalized feed) and I think many other. This way you can always revoke access to feed by simply changing token.
It has one disadvantage - it is not "protected" by password, so everyone who has can guess (or read from config files of your reader) URL has access to your feed.
And never, NEVER, put anything sensitive in this feed. Put only short summary and require users to open browser, log in and read more.
Try using the RSS feed url in format:
https://USERNAME:PASSWORD#URL
For a Basecamp project feed, this url might be:
https://bigguy:jellydoughnuts#basecamp.com/1234567/projects/89101112.atom
But it's really not a good idea to leave your password within a text field of one of these services -- even if you trust the service.
So, the safer solution is to use an intermediary that can safely store your credentials, access the protected feed, and republish the feed contents at a publicly-accessible url. Basically, we want a public proxy for the protected feed.
I use Yahoo Pipes to accomplish this. This pre-built Pipe makes it very easy to set this up.
Related
one question, maybe it's a bit longer, but i really hope someone can help me 🙏
I've been reading the docs but simply can't figure it out.
Is there a way i can create a signup feature where user creates an account (only simple one, email and pw) , and that account data is saved somewhere in a json file
And then the user can login via post method by typing his credntials.
And if credentials are correct (out of any other credentials there are in that particular json file) he gets a random jwt.
I mean i know i need to set up the rules if email and pw match any user and pw from the json file
Thanks!
Mockoon offers mostly stateless and independant endpoints mocking. Which means, there is currently no easy way to "code" it for such advanced use cases.
You can simulate a POST /signup and POST /login call, make sure the request looks OK by using Mockoon's rules, but they will not be linked and the credentials will not be persisted.
A system of CRUD endpoints is currently under development but it will allow for JSON manipulation only, not the kind of behavior you describe which is also very close to a production application.
I'm building a service that provide some readonly information that is going to be used in multiples websites, some with login and some public.
I dont want to make the api public to any website so I'm not sure what auth method i should use. I have some ideas but I don't want to reinvent the wheel.
I was thinking on have the backend of this sites request a token to my server using a secret/password/private_key then they should pass this token to their front end and pass it with each request to my server(their front end will comunicate directly with my API)
If your public non-authenticated API is accessible by your site, there's no way to stop other people from consuming this API and stealing your data.
You can stop other websites from directly taking data from your API (by not using CORS headers), but if your website is showing data from your API publicly, then assume anyone else can.
If your business relies on not being possible, rethink your business model. If data appears on the screen of a random user, it means that user can take that data and put it somewhere else. It's how the web works.
I totally agree with #Evert. Having said that, there are some ways you can use to make public API accessible to some and not to all. It will not be perfect, and using some kind of API tokens will be a better solution most of the time, but it might suit your needs.
First of all you can use firewall rules and allow connections from certain IPs only. Simple and will work as long as the source IPs do not change.
Another idea you can use: look at youtube and how private videos work. There is a secret in the URL. With enough entropy you can build publicly accessible URLs this way which can be used to share a simple link with friends, but will be hard to guess by others. There are drawbacks to this technique. You may only allow people to share their content this way, as they have always the rights to make the link public by pasting it into their tweeter/yt/other.
I would like to use 'https://webchat.botframework.com/embed/QuizHS?s=YOUR_SECRET_HERE' to integrate it with Web Application.
But, I would like to secure the conversation by passing token to it as Secret key is in querystring, so that no one can copy above link directly and use it in any other application as this data contain confidential data.
This was answered extensively by Dan Driscoll here: https://github.com/Microsoft/BotFramework-WebChat/issues/428
For purposes of this discussion, we're going to treat secrets and
tokens to be the same thing. We can go into detail on those later if
you want. I'll refer to them as "secret/token" for now.
To access a conversation, you need the secret/token and a conversation
ID. These values are sometimes glued together, and are sometimes in
separate variables. Sometimes they're in the URL, and sometimes
they're stored in JavaScript in memory. These are similar to a user
token, stored in a user's cookie.
In all cases, these values are accessible to a user sitting at their
own computer. They can read their own URLs, they can read their own
JavaScript variable state, and they can read their own cookies.
If they send any of this information to someone else, that person can
impersonate them. If my bank emails me a password reset link, and I
share that with someone else, that person can reset my account
password and log in to my account.
Our iFrame uses URLs to pass these parameters, as that's an adequate
level of security in many cases. (Have you ever visited a website,
manually extracted the URL to an iFrame, sent it to someone else, and
expected your session to remain private? Probably not.)
If you want additional security, you can skip the iFrame and send your
own secret/token inside JS or a cookie. Your JS can extract that and
send it to the Web Chat JS object. Once Web Chat has the secret/token,
is exclusively uses HTTP Authorization headers to send those values to
the Direct Line service.
I want to display a user's wall feed and news feed on my site. How can I do this?
Is there any way to pull the feed without having to get an authorization token?
If I need a token, how do I get that?
The proper (I would go so far as to say "required by Facebook's terms and conditions") way to do this would be to get an authorization token, which involves a pop-up div asking the user if they would like to permit your site (application) to access their information.
You can customize the level of access you'd need and they would be prompted only for that. By accepting, you'd be able to access a token within their cookie. Armed with that token and your application ID and your "application secret" you can make requests to the Facebook Graph API for any data you'd like. (You use the application secret to decrypt the user's cookie, from which you obtain the access token to pass to Graph API requests.)
It's not as simple as just scraping their wall and displaying it, you'd be responsible for grabbing the individual pieces of data and organizing the display.
Edit:
In response to your comment, here is a quick tutorial for working with cookies in .NET. A Google search for "ASP .NET cookies" or "VB .NET cookies" will yield much more as well. There is an example (in PHP) here demonstrating how to decrypt the cookie. I haven't found any .NET examples, but the code here is pretty straightforward. The cookie name is "fbs_" + your application ID.
It appears to be a delimited string, so just read in the whole thing in your debugger and see what the value(s) look like. The value you want appears to be called "sig" (but, again, debug to make sure) and it looks like they're using an MD5 hash to obtain it. You can read up on what the md5() function in the PHP code is doing here and it should be easy to find a .NET analogue for that.
Once you have the access token, it's up to you how you want to get the information. I'd recommend doing it all in JavaScript just to offload the whole thing to the client's browser, not to mention that most samples you'll find online (such as in Facebook's API documentation) will be using JavaScript. But if you want to do it all server-side, Facebook's C# SDK will be of some assistance. You basically pass it the token and the Graph API path you want and it returns a JSON object with all the data.
I'd like to be able to give my users the ability to display their recent tweets on their profile on my website.
I have a PHP twitter wrapper and understand how to make API calls etc, but I'm just wondering how to manage the user information.
What is the best practice here? I want them to be able to enter their credentials once, but I would imagine storing everyones username/password myself isn't the best way to go about it.
Is there a way to make an authenticated call once, and have twitter remember it?
Should I store the usernames/passwords and then just make a call when displaying the tweets?
Any advice here would be great.
Thank you,
Use OAuth, no need to ask users for their passwords:
http://apiwiki.twitter.com/Authentication
I think everyone would/should probably agree that storing the twitter usernames/passwords is bad, I can't believe they ever created a situation where you needed it.
You should never store unencrypted credentials of any kind. If your solution involves holding onto a plaintext password, even for a brief time, you need to rework something.
Absolute best practice would be to hold no information yourself - use cookies or OAuth to handle your authentication. A session token or cookie can be disabled by the user at will, giving them control over the behavior of your site.
Next best thing (although still pretty undesirable) would be to hold non-reversibly encrypted credentials to resend to Twitter whenever you need to display tweets.
You don't need their passwords to pull their latest tweets, unless their profiles are locked, simply pull the feed from http://twitter.com/statuses/user_timeline/username.rss
You should look at Twitter's OAUTH support (although they have disabled it). This enables you to prompt the users once, and then store a response from twitter which will allow you to post
Tweets that you would want up on your web site are generally public anyway.
If you did need to authenticate somewhere (perhaps allow users to send new tweets) on a user's behalf, the best practice is to prompt the user at the time you initially authenticate and then store whatever authentication token is returned by the resource rather than the credentials used to get it.