I maintain an online application that use most of the pages in PHP, but some pages uses for a good reason ASP.NET. Users can login in the PHP part. Is there any option to control or a certain PHP session is active inside the ASP.NET page? Both pages are hosted on one server.
You could build a web service on the PHP side that would allow to perform that check.
You would then call that webservice from the ASP.NET application.
You have to be very very careful however. A service like that would have to be highly secured, because this could provide a way to session hi-jacking, since it provides a way to validate if a certain session exists or not.
You could secure it by only restricting allowed IP(s) or using a form of authentication.
There are different ways you can build webservice.
You could write it a simple page that just does whatever logic you want and then returns a result in JSON or XML (that's the lazy and ugly way of doing it). If you are using a particular framework, you could look to leverage that framework in order to add that service. All major frameworks have ways to do that (Symfony, Silex, Laravel, Yii, Zend, etc.). Zend Framework offers something called Apigility that makes building Restful webservices very easy.
Your ASP.net application, will also need to have a token coming from the PHP side, so it can be used to identify the session.
On the PHP side, you would need to store somewhere that the user is logged in.
This also can be done in different ways and depends on what you want to achieve.
For example, you could store in a database a timestamp along with a token indicating when was the last time you detected an activity from the user. Then, your webservice would check against that db for the token and see if the lastActivity timestamp has an adequate value (you would have to define what adequate means, e.g. not older than 30 minutes).
Related
There is any way to check the login status through different programming language?
Right now I'm using three session (same name) that starts at the same time after the login process, using ajax.
Right now, the login.html form is processed on three files: login.aspx, login.asp and login.php but it's seems too slow and weird. I'm combining three different services from the same company into one, after re-building the users and others common tables in mysql, everything seems to work fine, but I'm really scared about security bugs.
Just to let you you know, I have to check the login session status before any ajax callback, so if the user is working on an ASP page calling PHP through Ajax, may be that the session is still active on the ASP, but expired on the php file.
Any valid method to check all in one time? I can also accept a cookie solution but how to make it readable between php, asp and .net?
This sounds like single sign-on to me. Let's try to split the problem.
There is any way to check the login status through different programming language?
You're not really interested in the language used. Any language, given the same info and algorithm, would decode with success the same encrypted data. I guess you're instead having problems because PHP's application logic regarding this point is different from the ASP's one.
So for the first point, you can
Implement / normalize the same session checking logic among all of your apps. This is probably unfeasible, because you might be using Laravel here, and ASP.Net on the other, and the two are probably slightly different in this regard. If you can, do this, or...
Look into JSON Web Tokens. I won't go into detail, but these were more or less designed to solve this class of problems. They are also easy to handle, but be aware, there are aspects you have to take care of when using them for user authentication.
[...] Just to let you you know, I have to check the login session status before any ajax callback, so if the user is working on an ASP page calling PHP through Ajax, may be that the session is still active on the ASP, but expired on the php file.
Not to be that guy, but some concepts are somewhat deformed here. Sessions don't expire on files; they normally are setup with a given expiration time and a given domain. So generally speaking, a session opened from a PHP app, and stored on a cookie, then read from an ASP one shouldn't change, given that no difference exists between the two app's session handling logic.
Any valid method to check all in one time? I can also accept a cookie solution but how to make it readable between php, asp and .net?
For both of the solutions i suggested above is, especially for the cookie one, it's important you make the apps absolutely identical in respect to session handling. While this is trivial with JWT (as there's barely any logic on the app's side), this may prove to be harder with cookies if the authentication logic comes from some one else's code (as in a framework).
I haven't asked about single sign-out, and at this point i'm afraid to ask :). But these are some guidelines:
If going the cookie route, be aware of cookie's domain. A cookie is normally valid for every request coming from the website domain (name.com), but you may have some of your apps under a subdomain (like, phpapp.name.com). In this case, be sure the cookie created from the given app is valid for the whole domain, and not just the subdomain. And make the apps available at subdomains / pages under the same domain. Cookies don't work cross-domain, and you have to deal with that, since cookie domain policy is enforced at browser level.
Launching three AJAX calls means triggering three login procedures. I suppose all of these would terminate, at some point in the future, and all of those would be storing / rewriting the cookie. If the apps understand the same cookie, it's mandatory you open the login process on just one of them. This would store the cookie, which would then be automatically picked app from, say, a page in the second app, giving you a seamless transition into a logged-state in the second app.
JWT would normally require some JS work, which you may like since the same script can easily be loaded in all of your apps. On the other side, you can be sure that different server libraries handling JWT would all work the same for you, thus ensuring compatibility.
Personally, i would look into JSON Web Tokens.
You can develop your own session provider which stores data in a separate place (for ex. in database or files). Then everything you need to do is write some code in every environment to handle your session information from that provider. Because you use only one source to store session information there will be no problem with synchronization between any of yours environment.
If you need then you can use a webservice for exchange session information between every environment and session provider. Every application can use security connection to get and set information about session from that session webservice.
I think you can do this!You can create provider which stores data into database. Then Write some cool code to manage your provider.You can also use webapp or sevice.Every service use security to get and put information.
I chose MySQL after looking between MySQL and SQLite for accessing because my iPhone app needs to pull information from an online database that is already in MySQL.
I believe the traditional way of accessing information would be: To have a php file on the server that does the accessing for you.
The iPhone app would call this php file and it would return the results.
iOS app will call http://somewebsite.com/index.php?id=234 and the website would print out the username of id=234.
Now, how secure is this process?... I would obviously use prepared statements and https. But what if someone found the URL for this website? How do I protect myself against misuse (someone could generate a list of all my users)? Is this the standard way to have your iPhone app connect and get info from a database?
Edit: Furthermore, lets say I needed to create an app login page... I have a MySQL database with username and password (hashed obviously). Would it be safe to use $_GET variables to see if they are authenticated. Like for example: https://somewebsite.com/checkauth.php?username=test&password=C3LyiJvTCQ14Q and have the php print out yes or no. Picture examples below:
I would assume the above method would not be safe to do... but I need to be enlightened.
Also, I'd prefer to stay away from calling the database within the app using third party API, not supported by Apple.
The best way to go about this would to setup an API to interact with the database on the server and your iPhone app just queries the API and returns the data in a machine readable format such as JSON, see http://en.wikipedia.org/wiki/JSON and http://json.org/. So for user login the server would return maybe something like:
{
"result": false,
"error": "Invalid username or password"
}
This would be generated by PHP with the following code:
echo json_encode(array(
"result" => false,
"error" => "Invalid username or password"
));
Also note that, you should use HTTP response codes in conjunction with this, eg 401 for unauthorised.
JSON can use boolean and other data structures within its format. Nearly all major languages have support/libraries for it.
The benefits of this is that it allows you to build other applications using the same API such as an android version or an actual website.
This SO question is a good starting point on the security of mobile applications:
Creating an API for mobile applications - Authentication and Authorization
The main points are make sure to use HTTPS. When sending over user credentials you could return a user token (api key) that can be used for future requests and stored within the iPhone app for future access.
Eg: https://iphoneapp.com/notifications.json?key=98fy92473r92hAAIYEFG397qbqwiuUEAF
Your key should be sent in a HTTP header or in the POST so it is not recorded in logs etc...
Note: This is just a random string typed on the keyboard.
This method allows you to delete/regenerate the key if it gets compromised. You can also set rate limiting on the keys and various other parameters.
Another huge benefit is by building an API that your own app uses means that it will be maintained to a high standard and other third party companies can also use the API (if you allow them).
Edit: Furthermore, lets say I needed to create an app login page... I
have a MySQL database with username and password (hashed obviously).
Would it be safe to use $_GET variables to see if they are
authenticated. Like for example:
https://somewebsite.com/checkauth.php?username=test&password=C3LyiJvTCQ14Q
You should send that sensitive data using POST instead, but any service has to login at some point. Using HTTPS should help the most as it prevents eavesdropping. After the first authentication you can return the token and reap the benefits mentioned above.
As for the user login as along as your PHP conforms to good practices you should have no issues. See http://www.phptherightway.com/ it will help a lot if you have questions.
Definitely research OAuth and utilize that if you can/want to.
This is just a starting point and is NOT meant to be used word for word, further reading and googling is required.
If you're looking for an alternative to a "build an API from scratch" approach we've used a web based service called Kumulos available at kumulos.com for a quick and easy solution.
This service allows a developer to connect to a MySQL database and build the data model and APIs via a web page then deploy a native library to your platform. I believe you can also import an existing data model as well.
Once the data model is built on the web page you can then build APIs and specify input and output parameters. The APIs are modeled based on the type of SQL operation you are performing such as SELECT, UPDATE, INSERT, DELETE.
In your case you would want to model a login/authentication UI which accepts the username and (hashed) password, validates the data against the Users table and return the authentication results.
Once your APIs are modeled via the web page you can then "deploy" your configuration and generate native libraries for iOS, Android, PHP, and others.
The generated Obj C library gets dropped into your project and you make and respond to APIs using objective c calls and delegates.
Kumulos includes some other features as well like data export, API call metering, and what they call KScript. This is essentially the ability to wrap your call in javascript at the server (also configured via the web page) to greatly expand the flexibility and capability of the API call functionality you can build.
We've had a couple of questions or support issues over the past few months and their support has been top notch. Their backbone is on Rackspace. We've got about 8 or 10 production apps running APIs through them at the moment and are quite satisfied not having to hire an API developer :)
Many mobile applications use APIs to get and store information in servers. Figuring out some of these endpoints is not complicated, and having unsecured endpoints returning sensitive information is a dangerous thing to do.
The first level of protection of your API could be to create an "API key" that identifies the application. This key is stored it in the server and checked on every request. Request with no API key should return a HTTP 401 (Unauthorized) status code.
API keys are okay, but insufficient when some calls can only be performed by certain users. For example a user needs to update his information, only the owner of the information should be able to perform this call, and not another user. For this you can pass authentication information that identifies the user to perform the update action.
I do not recommend using username/password on every request, instead have the user authenticate once, and let the server send back authentication tokens that can be used by the application to perform future authenticated calls. Take a look at OAuth2 as a potential Authorization Framework. Also check out OAuth 2.0 - The Good, the Bad & the Ugly.
I suggest using BShaffer OAuth2 Server in PHP. Also see Best Practices for securing a REST API / web service for alternatives.
From your question it sounds like there is an existing subsystem, I recommend creating a simple interface that makes the subsystem easier to use, and reusable across multiple clients instead of modifying the subsystem to accommodate an API. This is commonly known as a Facade Design Pattern.
Many PHP Frameworks have packages to implement custom RESTlike APIs. Symfony has FOSRestBundle, FuelPHP has a REST controller out of the box and CodeIgniter has a REST server.
To summarize:
Create a simple interface to access information from the existing system (a REST API).
Protect your private information using a proper authentication mechanism (maybe OAuth2).
Use existing libraries and/or frameworks to speedup development.
Your code will be reusable across multiple applications and platforms as a result!
if you want to access database from IOS Application and save data into database you have to use middleware solutio.
which is Webservice
Create Web Server In Microsoft ASP dot Net And Access That WebService in IOS Application With that you can communicate between two different OS.
return from Webservice is XMLdoucment which can be further parse with xml purser.
I am currently building a Flex 4 web app using PHP as my backend. I am using AMF to let the backend and flex application talk to each other.
How can I protect my AMF endpoint? Users can just decompile my flex application, find the URI to my endpoint and call methods. I need to ensure that all calls to the endpoint is done from within my application.
I would like to prevent somethig like this from happening: http://musicmachinery.com/2009/04/15/inside-the-precision-hack/
What are the best ways to achieve that?
Thanks :)
URLs aren't important. They're very easy to find out from any web application, and yet you still need it to have public access to them. There are a few things to do, first, if you're interested in the data security itself, you'll probably want to have your server running over https instead of http. If data security isn't crucial however (and it often isn't), you just need to have a quick and dirty authentication system.
I'm sure you can find many articles online or even frameworks made for authentication for php. In the past when I needed a very simple authentication, I would have my client send over a username and SHA1 password to an open authentication function on php, which would then create, store and return a session ID. That session ID would then be the first parameter of all the other php functions. Those functions would check the DB to see if the session ID is there or still valid (15 minute timestamp from the last time it was used) and if it is, go ahead with the function.
This is just a very simplistic way of doing things and will be good for a lot of small websites. If you need more security, send all of this over https to prevent sniffers to get the session id sent over the wire. After that, you're going into enterprise security which is probably overkill for what you want to do and will cost you an arm, a leg and your left testicle :P
I had a scenario and want opinion by you people.
I have different web applications developed in Django, Rails, PHP , I want all of them to share the same session data every time. Means if a use is logged in to a PHP app, it can automatically be logged in to Rails app and vise versa.
I know its some kind of Central Authentication Server. Some of these are cas, josso.
What do you people have opinion for it. I want the behavior like Google Apps, when i am logged into Gmail, i can automatically logged into GoogleDocs as well.
Please share your thoughts, that how to implement this scenario?
Google runs entirely off the .google.com domain, which is why they have absolutely no problem using a single cookie to identify you across applications. If your applications all run on the same domain, I'd say go ahead and write a custom implementation to authorize users with a shared session cookie.
However, in the more likely event that this is not the case, you're better off implementing one of the more popular and wide-spread SSO methodologies like OAuth or OpenID seperately in your applications and either giving your users a centralized application at which to authenticate, or let them authenticate via external providers (like Facebook or Google, which supports authenticating via OpenID)
You can run your own OAuth or OpenID endpoint at which your users register and then auth via this endpoint on any of your applications.
In PHP, you can use session_set_save_handler to specify how the session is persistent and restored. I guess Django and Ruby On Rails provide similar means
just store the sessions in the db ore handle them yourself completely
the best approach would be to create a special table for this
watch out as php want to store this data sialized so unserialize before storing in the appropiate field as serialized data is too hard to handle
in php you have
$_SESSION
and session_set_save_handler()
but i think it is better for you to make it yourself
make sure all sites use a single cookie domain(ajax onload(to try getting this coockie), or keep the same domain)
In my apps I use SESSION to store a value of logged in user. For example $_SESSION['site1']['bakcend']['loggedin']=1; Than put a session check on other places. They of course are all under same domain.tld If you use above example $_SESSION['site1']['bakcend']['loggedin']=1; you will need a lot of checks if you have many sections. But this is only an opinion, there is a place for much more flexibility.
You can use cookies too.
I'm working in a website that is going to work like a landing point, providing a specialized service for many other websites. Users log-in to different sites and those sites have links to my website.
Now, I want to create my website using asp .net, and also I want to be able to use SSO (Single Sign-On) so the users doesn't have to authenticate again when they land on my site.
The problem is that most of the websites that are going to use the services of my site are in php, when users login on these sites, all the authentication process is handled and also a lot of data is fetched into the Session variable; what I want to do is to be able to capture all the data in the session variable coming from the php page, in my asp site.
I don't know if this is possible, maybe this can be done in another way
So far, the only thing I've been able to do in the asp is, ask for a parameter in the url and using that parameter query the database to get all the data that was already in the session in php.
So if any of you know a way to do this.
Thanks
My company does this extensively. Our app passes information from our software to other systems such as CRM's, appointment schedulers, data aggregators, etc. In cases where systems are radically different and access is not explicitly given, the best solution we've found is to use cURL and negotiate a data interchange via API. Setups with people of varying technical abilities can be challenging (we've actually provided code for several systems we wanted to communicate with) but in the end it's efficient and secure.
Unlike many UI guys, I'm a fan of OpenID for single login. However, that doesn't pass all the data you likely want to interchange between the sites.
You could either use a database as a session store point accessible by all pages. this makes it pretty easy to access session data by either php or asp.
I think this would be the mos performant way.
If you don'T want to give the other php sites any access to your databases you also could create a special page not for vewing in asp and tell the php sites to drop the session contents via curl there and in that sie then save the session stuff in your database.
It's not clear from your question whether you are hosting both ASP and PHP websites on one server or if your ASP site will be used with other third-party sites.
If you run and manage the ASP and PHP sites on one machine, then storing session information in the database will be the way to go and isn't too difficult. You'll need to make sure that the session data you store in the database can be read by both PHP and ASP--I'd pick something simple like JSON. A url parameter would be a bad way to get at this data, as it makes user information available to anyone who could guess a user id.
It's not so simple, however, if you want to provide SSO capabilities with third party sites. In this case, you'll have to implement an authentication API that the third party sites can call to log their user into your site when they initially authenticate the user on their own.