The idea is the following.
The user sends credentials to the server (username,password).
Server tries to login to the website and parses useful data. Some
data remains to server in order to provide notifications if
something changes in the next parse.
Server sends data to the user application.
User interacts with data and makes requests to server to receive
data
loop between 3,4
logout
The problem is security and privacy. How to exchange this kind of information between server and the application securely? Also i don't like the idea of people sending me their credentials.
How to implement such a thing knowing that the site i am screen scraping does not provide an API to do this job?
Instead of storing their login details you could store the session cookie and reuse it until expires. Hopefully it would last step 5 but if not you could ask for their login details again.
The only specific problem here is the screen-scraping, the other tasks are too vague to answer.
I can recommend screen-scraper.com (I am not affiliated in any way).
Related
I have a website and my own server and database, I also have an native Android app. I need to allow users to be able to sign-in with their account from the website inside the app in order to sync information and other things they need to use. I've been stuck for a couple of days trying to figure out how to do that. I've found a lot of content regarding OAuth and AppAuth but they are focused on using an OAuth API to the job. Back on my server, I use Hybridauth for social login, but users can also register directly on the site. How would be the proper way to allow my users to sign-in to their website account through the Android app?
You're overthinking it. OAuth isn't meant for users to log in, it's meant to enable external services to access data on behalf of a user.
To make a user log in? Create a POST endpoint on your webservice named login. It should take two parameters- username and password. The body of the login service should salt and hash the password, then check if the hash equals the hash stored in the db for the same user. If so, you're logged in and you return a success packet with a unique token to authenticate you for later requests. If not, you return a failure. The Android app would ask the user for their data, then send a request to the endpoint. On success it saves the token and sends it in all future requests to authenticate yourself, either as a parameter or as a header.
This is of course the simplest possible version. More advanced features would include expiring of login tokens, refresh tokens, possible lockout if you have too many bad requests, etc. But the above is the basic idea. Although really I'd look for an open source solution you can take, as there's quite a lot of complexity when you get into all the stuff mentioned above, and its a place where a mistake that leads to a vulnerability is probably the most dangerous.
We have an existing web application we developed and needed to port over to an android application for people in the field. So we have a shell of an android application that just points to the URL and displays it. I want to save the user credentials so if they timeout/close application and re-click the application it will auto log them in always after the first time.
I am looking at SharedPrefrences as other threads here have done, but not sure how to capture the creds from the web input elements. Can I use SharedPrefrences to accomplish this still? If so how do I target that input?
You do NOT save the user credentials. Ever. Saving them means they can be read by malware. And no, encryption can't help as the encryption key would need to be in your app or on your filesystem.
Instead, you have your login API return a token. This token will be sent back to the server with every request (either as a parameter or a cookie). The server will then use this token to look up the user id on the server and figure out who it is. That token can be saved to SharedPreferences. (This is the simplest version, there are more advanced things you can do as well, but this is sufficient).
Why is this safer than storing the password? Because passwords can and frequently are shared between multiple apps, so losing a password can compromise multiple accounts.
BTW, this is also how webapps work. They don't send the username/password with every request, when they login a cookie is saved with a token, and its sent back with every future request.
I have some doubts about how to send a message from a Java Rest Server, to an Angular Client. I have read about WebSockets, but Im not sure if it suits what im looking for.
We use a token-based authentication , and when a client logouts, we choosed to simply remove token from client. Until here everything is correct. Problem is that our system includes a functionality that allows admins to logoff online users. As clients can't notice that they where logged off, they can't remove token. I'm looking for a way to send a message from server to an specific client, so It can logouts from ClientSide, and remove its token.
Is WebSocket best way to do this?
Thanks in advance.
Here is what I would do. When a user is logged off, which can actually also happen when the session expires, nothing will happen until the user performs an action. This action might require a backend call which can then return a 401 html code.
When you really immediately want to redirect the user to a login page, you might indeed need web-sockets or if that is not an option, hit your backend with a certain interval to validate the session
I'm have implemented a module for Java web application that users will need to request for them to access the secured data. It works like this: when users that does not yet have access clicks on a certain link, a request is made and is received on the server side. It now generates an email and sends to people who are "approvers". The email contain links on approving or denying the access of that user.
Approved Link:http://hostname/App_name?action=actionClass&approved=true
Denied Link:http://hostname/App_name?action=actionClass&approved=false
Now the question is, is there a better way to do this which also takes into consideration the security?
I did try to look for other posts that are related to this but the results don't seem to be touching on this regard. If there are any that I have missed, I would appreciate if you can also point them so I can revise the question.
Thanks in advance
I'll assume that you are authenticating the users when they click on the given link, because otherwise it's just bad mojo.
You can have some privileges assigned to that user and check that to see if you are going to allow the approve or not.
That depends on how you are sending out the email. Assuming you are doing it client-side, then a user could intercept their own approval link, which clearly you don't want.
A better way (assuming you aren't doing this already) would be to send the user information (via HTTPS of course) to your server and then have the server generate and send the email. This way no one has access to the approval link except those emailed by the server and those in control of the server (you hopefully).
I am in the middle of developing a PHP social media web application which will be supported by various web services each operating a REST API. Web services will probably be implemented in Java with MySQL data layer but the whole point of what I am trying to do is make it really easy to implement modules in different languages/data stores depending on what is approriate.
So for example when the user logs into the application via a login form the PHP code connects to a web service and POSTs the username and password to check if they should be authenticated. I would normally at this point start a session and store it in a session data store.
Another example could be if a user sends a private message to another user. The message would be POSTed to the private messaging web service which would take care of all the storage. Similarly the web service could be contacted to retrieve messages for a user.
Although I understand how to implement the REST web service in Java and make the connection to it in PHP I am totally unsure as to how to secure the data being passed and make sure that it is the users data being returned. If for example I want to get all of user As private messages how does the web service know to return that users. I could pass that users identifier as part of the GET url but then surely any old user could just figure out the GET url and use it to look up other peoples messages. I thought maybe I could pass over the session identifier and IP address which would allow me to check the session data store and make sure it is the correct user?
To secure the data that is important - like the username/password I thought I would just pass it over SSL.
Hope this explains my problem better.
Thanks
Take a look at HTTP Digest authentication. Most clients should support it, and it means the auth details can be passed securely with each request as part of the headers without interfering with the payload of the request itself.
I think requiring OAuth is a good choice. Your end users should appreciate that other websites don't need to ask usernames and passwords to access their data. As far as SSL, it's clearly worth doing if you can. You'll have to see if the performance trade-off is acceptable.
Keep in mind that your api must mimic the HTTP protocol.
Http is stateless, and by adding any Sessions or so, you're trying to fake an "Alwaysconnected" method.
With a LoginForm, it's like I'll have to send two requests for each calls ;)
These are basically 2 questions.
When privacy is a concern I'd go for the safest option: Serve data over SSL (via HTTPS).
As far as authentication is concerned, there are several possibilities. Basic over SSL is one of them, but a simple login form with a cookie can be another one. (ASP.Net Forms Authentication for example.) This all depends on how you want to implement your authentication mechanism.