We are providing a form inside an iOS app for users to be able to fill out a survey. The submission works against our rails server, however, we don't require any user authentication since it's a public facing app. My concern is that with a properly configured curl command, someone could easily write a script that could fill up the database very quickly with bogus data. I could probably add some rate limiting that might help, but what would be a good way to minimally prevent someone from doing this? You could maybe limit it by using some obscure user agent that couldn't easily be guessed, but is there some sort of token scheme or some similar that would work that wouldn't require us to implement user auth? I'm not looking for absolute security--just a basic deterrent. Any ideas? Thanks.
Related
I am looking to set up 2 rails apps (with the same tld) which have single sign on and share some user data. If I have railsapp.com I will have the second app set up as otherapp.railsapp.com or railsapp.com/otherapp. I will most likely have railsapp.com handle registration/login etc (open to suggestion if this is not the best solution).
So lets say I sign up and upload an avatar and start accumulating user points on the main-app, I can then browse to the other-app and my profile there has the correct avatar and points total. is there an easy way to achieve this? Do the available SSO solutions create the user in the second app with the same user ID? if not, how are they tied together? (ie how can I query the other app for information I would like to be shared across the 2 - user points and avatar) I was initially looking at sharing a database or at least the user table between the 2 apps, but I can't help thinking there must be an easier solution?
I think the simplest solution is if you set the cookie on the .railsapp.com domain, then it should be sent when you do requests to otherapp.railsapp.com or any other subdomain (just stressing that as it might be a security concern). Remember to mark the cookie as secure!
And a extra bit you might need to make this work, is to store authentication tokens on a database so they can be shared between the two apps.
Disclaimer: I don't have much experience with Rails anymore, so I'm not sure if some of the frameworks like Devise can do something like this out of the box.
Edit
Got curious and ... google had the answer: http://codetheory.in/rails-devise-omniauth-sso/
I'm writing an app that make some calls to my API that have restrictions. If users were to figure out what these url routes were and the proper parameters and how to specify them, then they could exploit it right?
For example if casting a vote on something and I only want users to be able to cast one vote, a user knowing the route:
get '/castvote/' => 'votemanager#castvote'
could be problematic, could it not? Is it easy to figure out these API routes?
Does anyone know any ways to remove the possibility of this happening?
There is no way to hide AJAX calls - if nothing else, one just needs to open Developer Tools - Network panel, and simply see what was sent. Everything on clientside is an open book, if you just know how to read it.
Instead, do validation on serverside: in your example, record the votes and users that cast them; if a vote was already recorded by that user, don't let them do it again.
Your API should have authorization built into it. Only authorized users having specific access scopes should be allowed to consume your API. Checkout Doorkeeper and cancancan gems provided by the rails community.
As others have said, adding access_tokens/username/password authorisation is a good place to start. Also, if your application should only allow one vote per user, then this should be validated by your application logic on the server
This is a broader problem. There's no way to stop users from figuring out how voting works and trying to game it but there are different techniques used to make it harder. I list some solutions from least to most effective here:
Using a nonce or proof of work, in case of Rails this is implemented through authenticity token for non-GET requests. This will require user to at least load the page before voting, therefore limiting scripted replay attacks
Recording IP address or other identifiable information (i.e. browser fingerprinting). This will limit number of votes from a single device
Requiring signup. This is what other answers suggest
Requiring third-party login (i.e. Facebook, Twitter)
Require payment to cast a vote (like in tv talent shows)
None of those methods is perfect and you can quickly come up with ways to trick any of them.
The real question is what your threat model and how hard you want it to make for users to cast fake votes. From my practical experience requiring third-party login will ensure most votes are valid in typical use cases.
I currently work at a school and have an idea to create an app that allows students to contact a grown up (for example, the principle) anonymously through an app. The app would quite simply consist of a contact form. I am trying to find out the best, and easiest way to achieve this without setting up servers with a separate API. Does anyone have a suggestion on how to achieve it? Is there any way to set up an e-mail form with a pre set recipient and a built in sender-account? Please guide me in the right direction.
You would need to implement an SMTP client. You can use open source code like skpsmtpmessage
It's likely that their example app could be your solution.
Your biggest problem will be the deployment. You definitely need to pay an $99/y developer account and add all the students device ID's to your account (with a maximum of 100 devices/y) or register all of them as beta tester (I don't know the limitations).
Probably this isn't doable so easily, as it seems you don't have iOS developing experience so far. Maybe you can find something on the app store that works with self hosted databases. But you definitely need to host some kind of webApp/API.
You may want to give Appygram a try to handle the back-end if you are able to set up the contact form itself. While it's a separate hosted API, at least you don't have to build/manage it.
Appygram is a free web service that would allow you to configure all the details such as which adults could be contacted, their point(s) of contact (i.e. email address), and it would process and send all the submissions for you. All your app needs to do is send a form post request.
A nice thing about having this information outside of the iOS app itself is that you can change the contact details on the fly without requiring an update to the iOS app itself. Whether you use Appygram (which, since I contribute to it, I am slightly biased toward!) or something similar, I would say that since this is for students, I would recommend a solution that would allow you to update your configuration without requiring app updates.
Finally, I'd second what Julian said. The challenge here could be with deployment. One possible alternative would be to make this a mobile-friendly web page accessible only via student login or on the school network (or both). Would probably be easier development-wise and wouldn't require installs nor the hurdles that Julian described with device registration, etc. And, Appygram would still work with this setup as well.
Good luck!
I am developing an ASP.Net MVC4 app that uses windows authentication. One of the requirements of the app is to prompt for credentials when an item is edited, even though the app is already aware of the user's credentials (User.Identity.Name). This requirement is necessary to meet FDA software validation standards.
I read I can do Response.StatusCode = 401 and that will force a login prompt, but I am not aware of a way to capture that information so I can save it with the data. I also read doing this has other side-affects.
Would I have to use a mix of forms and windows authentication? If so, does anyone know of examples that might help me get started? Like I said, I have to capture the user credentials so I can save it with the data.
The basic purpose of the prompt is to ensure that the person editing the data is who they say they are. For instance, I can walk away from my computer with the app still open and someone else can come along and change data in my name. Hope that makes sense.
Thanks.
Anything dealing with reauthorization will need to be customized for your specific needs.
My recommendation would be to open a (client-side) modal with username/password, and pass that information along with the rest of your POST data. Obviously you will need to have a fallback for <noscript>, if that's a requirement as well.
I need to develop an application which should help me in getting all the status,messages from different servers like Twitter,facebook etc in my application and also when i post a message it should gets updated in all the services. I am using authlogic for authentication. Can anyone suggest me what gems/plug-ins i can use..
I need API help to get all the tweets/messages to be displayed in my application and also ways to post the messages to the corresponding services by posting it from my application. Can anyone help me from design point.
Walk through what you'd want to do in your head. Imagine the working site, imagine your webapp working before you start. So your user logs in (handled by authlogic) and sees a textbox called "What are you doing right now?". The user fills in a status message and clicks "post". The status message appears at the top of their previously posted messages.
Start with the easy part. Create a class that posts to two services. Use the twitter gem and rfacebook to post to two already defined services. In the future, you'll want to let the user associate services to their account and you would iterate through the associated services and post the message to each. Once you have this working, you can refactor or polish the UI a bit to round out this feature. I personally would do the "add a social media account to my profile" feature towards the end.
Harder is the reading of the data (strangely enough) because you're going to have to figure out how to store it. You could store nothing but I suspect you'd run into API limits just searching all the time (could design around this). I would keep a little cache of posts associated to the user's social media account. In this way, the data model would look like this:
A user has many social media accounts.
A social media account has many posts. (cache)
Of course, now you need to schedule the caching of the posts. This could be done manually, based on an event (like when they login) or time based. So when the update happens, you load up the posts for that social media account and the user will see the posts the next time they hit the page. For real-time push to the client's browser while they stare at the screen, use faye (non-trivial) and ajax to pull the new posts to the top of the social media stream view.
The time based one is tricky because you'd either have to have a cron job run or have rails handle it all with a gem like clockwork. But then you have to leave rails running. I've also solved this by having a class in /lib do all the work and a simple web call kicks off the update. But it wasn't in a multi-user use case. So that might not work. In any case, you'll want to have some nice reusable code for these problems since update requests can come from many different sources.
You'll also have to deal with the API limits. When pulling down content from twitter, you won't get everything. That will just have to be known by the user or you'll have to indicate a "break in time" somehow.
The UI should be pretty easy (functionally anyway), because you know which source the post/content is coming from. It'd be easy to throw a little icon next to the post to display which social media site it's coming from.
Anyway, good luck, sounds like a fun project.