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.
Related
I'm considering building a security service in PHP that would hold user credential information , the most important of them would be tokens of logged in users. This service would be accessed by some kind of an API (REST, SOAP, whatever) by another API (an external user connects through a website API which checks credentials in another API - the one we're considering now).
There is a possibility to store tokens (and other information) in RDBMS. But this solution doesn't seem clean to me (tokens will remain in the database even if they're already expired, I would have to implement a mechanism for clearing expired sessions, etc). I was thinking about using native PHP session management ($_SESSION). Is that possible? Does anyone have experience with doing such things?
I thought of following problems:
when a PHP-based website is deployed on www server, users access the URL via browser and their native sessions are created using browser cookies. If there was one webpage API that would connect to security API, would there be only one session object all the time? Is it configurable?
How precisely sessions are created and how can I affect the mechanism (e.g. not to base it on cookies)?
My advice would be to use a database.
Let me start out with explaining the general concept of sessions. Sessions can be seen as server-side cookies. The location of the $_SESSION variable storage is determined by PHP's session.save_path configuration. Usually this is /tmp on a Linux/Unix system. Sessions have a session-parameter of the client associated with them. When a session_start or something like that is issued, the server will retrieve the file/session based on the session-parameter provided by client. As these are just stored files, it is possible for the server to read the sessions of other clients.
That brings me to the second problem you describe. If I am correct you want to have some api request information about a session of some user. Based on the first paragraph, you hopefully understand that the purpose of sessions isn't to use it as some sort of global storage. Of course it is possible. You could have the foreign APIs include the session-parameter or you could read the session-files manually, but to me these seem dirty fixes. It just isn't what sessions are build for.
The only other thing which attracts you to using sessions is the automatic timeout of sessions. However this simple logic you could easily implement when using a database. What you should do is register the time of the last activity of the user in your database. When an API requests the data of a user you can simply check whether the current time - the last active time is lower than a certain threshold. If that is not the case, the session expired and, at the same time, you can drop the session from the table. This is the more or less the same general method as sessions internally use, which requires no regular cronjobs (although they still could be useful to cleanup the database) to remove sessions.
So don't be afraid to use a database to store data, after all they are build (and optimized) to do that exact thing.
I have an PHP Application. If I have logged in that application I am trying to pass the parameter as querystring through an iframe to the asp.net page.
Is there any other way to implement other than using an iframe?
Instead of having the PHP application submit data to your ASP application, it would be better if they could natively and securely share some of the data.
How?
Well, your goal is having one script tell the other that the user has been logged in, right? In PHP, this is usually done by putting something in the $_SESSION. Your ASP application can't read $_SESSION, though. You'll need to use something else.
When the user logs in, create a unique value. Maybe the result of hash_hmac over some interesting data? Whatever it is, it should be unique every time it's created and unguessable. Don't throw in things like the user's IP address or the current time.
Save the unique value to a database table that both applications can read. Also store other information that will help identify the user, such as her identifier (user_id or whatever you have on hand).
So, the PHP code that logs the user in has created this unique value and stuck it in a shared database table. Now, the PHP application should forward the user to your ASP application. Include the unique value in the request.
When the ASP application receives the request, it will look for the unique value. If it's found, it can look in the shared table. If the value is found in the table, it can then take whatever measures it needs to in order to mark the user as logged in.
Once the ASP application has logged the user in, then it should delete the unique value from the shared table. The user can be forwarded to wherever she was going in the first place.
By making the key usable only one time, and only after a successful login in the PHP application, you'll reduce the possibilities of abuse by malicious or curious users. All of the important information will be hidden in the shared database table.
Be warned that this is an overly simplistic implementation of "single sign on" and is full of caveats and edge cases. While it might work for you, it might not be the best solution. Given your question history, it looks like you've been struggling with similar issues for quite some time. You might want to give some thought into using a slightly more "industry standard" SSO mechanism. SAML is the 800 pound gorilla of SSO standards. I normally wouldn't wish it on my worst enemy, but maybe it's the thing you're really looking for here.
Also, don't use iframes, they're cookie eating disasters in some browsers.
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.