I would like to enable my users (who are already authenticated in my application) to automatically log into their Cpanel accounts through API.
If I know the password of the specific account, then it will be no problem. However, I do not think that I can retrieve the password of any account? If I can, please tell me which API function to use? If not, what can I do to achieve what I want?
Thanks
Elcin
It looks like cPanel has a method for providing secure remote logins as documented here: http://docs.cpanel.net/twiki/bin/view/AllDocumentation/SecureRemoteLogins
You can find the source for it in /usr/local/cpanel/Cpanel/LogMeIn.pm
I have a PHP implementation of LogMeIn.pm ready to go (easy to understand and port to any other language) but I'm clearing it with the legal folks over at cPanel before I share it.
After speaking with cPanel's VP of Operations, LogMeIn.pm is now dual-licensed allowing modification and use elsewhere as long as a copyright and license notice stays intact.
My PHP port can be found here: https://gist.github.com/4440574 I decided to implement it as a static class to closely resemble the original but you can very easily turn it into a procedural function.
Using it is as easy as
LogMeIn::getLoggedInUrl('username', 'password', 'example.com', 'cpanel');
which will return false on failure, and on success a string with a URL that will log the user in.
If you're running PHP 5.3.0 or greater you can add this to a cPanel namespace (add namespace cPanel; on the line after <?php) to keep it from conflicting with anything in your application that you've already written (or will write).
Related
There is an application that we are using it both on XPiNC and browsers.
Before you can access the application, you must log-in with your user.id from lotus notes. The problem is there are several login msgboxes ( where you must again log in with your username and passwords ) saying:
The server says /xsp/.ibmxspres/dojoroot-1.8.1/dojo.
or
The server says /xsp/.ibmxspres/.mini/dojo/.en-us.
or
The server says /xsp/.ibmxspres/.mini/css.
or
The server says /xsp/.ibmxspres/.extlib/icons.
and so on. Even when I just hit F5 when I'm logged on in application ( there is, also, a computed field which displays the username ) those type of messages are being displayed.
What should I do as a developer? Or there must be some settings at the server?
I have the following ACL rights:
ACL: User type: Person and Access: Manager.
Effective access: all the checkboxes are checked except Full Access Administrator
Thanks for your time!
Ok, this should be straight out of the box ;-)
What I find strange is that the ressources you seem to be asked for access to use are some of the "built in" ressources (Dojo, css, etc.) in XPages...???
So first thing is really to test that this has nothing to do with your application:
Create a new application
Set a proper ACL that will force you to log in (Default reader or higher, a person called "Anonymous" no access)
Create a simple XPage and open it from the browser
What happens?
If everything works, then you need to add some elements that use the ressources (css, Dojo, etc.). Then what happens?
I guess you will see the same problems... If so, you need to have a look at the way you have set up your server for web access. Are you using internet sites? Do you use basic or session based authentication?
What does the ACL of your application look like?
What you experience could be caused by "realms" i.e. the "path" to which you log in. A simple example:
If you are required to log in to access the ressource /path/db.nsf/view/doc1?openDocument then your realm will be "/path/db.nsf/view/" - if then you try to create a document using /path/db.nsf/newDoc.xsp then you could be asked for access to the realm "/path/db.nsf/".
I must admit that I haven't seen these issues for quite a while - but that may be due to the fact that I control access to the database as a whole - if users need access to something inside the database I implement it using "public access". But first, let us hear a little more about your findings before we chase it as a realm issue ;-)
EDIT:
Ok, so you are using basic authentication. There are lots of good reasons to use session based authentication instead. However, that does not explain your problem. What OS are you using? An OS with file access in the file structure? Could it be that the user running Domino does not have access to the ressources? Have any (file) restrictions to these directories been set up? You really should not be prompted to login for these ressources....
Did you try another "new" application?
/John
Switch to session based authentication. The multiple prompts point to BASIC where you can't logout unless you close the browser
I'm working on a little node.js-project, and while googling alot, I kinda got a bit confused, but maybe some of you are able to point me towards the road again.
Several websites are generated by DocPad (excellent piece of software), and hosted on different domains.
All these websites shall now get a "login module" (which is also written in Node.js, using passport). Visually, it will look similar to the excellent login-slider from Web-Kreation (Here a demo). My plan was to use nginx and route all the /login-requests to the login-app, which is working fine.
The problem is rather related to the multiple domains, and the clientside implementation of it all. All logins use the same database.
Can I somehow use both together, and create the session-cookies from the Login-Module (which could use the same domain all the time)?
I'm answering my own question for reference, in case someone else comes across the same problem.
In the end, I solved my problem by having a bit of a different setup. Instead of a module, using the dns of each page, I use a central login-application for all sites. The sites itself do not require to access any personal information, so that's not a problem.
DocPad is still being used to generate the different websites (works excellent - I know I say this very often, but if there's a brilliant piece of software out, there's no reason to not mention it once in a while) statically, and all static content is delivered to the user using a CDN.
The login-system is a node.js-application using Redis as the only database. It is integrated via a simple iframe on all pages rendered by DocPad on login.example.com.
After successful login in 'login-app' you can create encrypted string with info about current user. You can pass this string back in get/post parameter with redirect to necessary domain. Encription key is known only to the 'login-app' and your websites. You can trust this encrypted data. It is necessary to make sure that every time the key is different for the same user. For example you can add the information about the time of login or random. After decrypting the data you can set authorization cookie for a particular domain.
I posted a variation of this question to the CouchDB user list and haven't received a response yet.
I'm curious to know if anyone else has built a so-called "CouchApp"; a pure HTML/JavaScript application hosted directly within CouchDB. If so, how did you handle user authentication? I'd like to be able to create a typical login form (username, password) and then use those credentials either against a view or some other mechanism before passing the user along to the application (while storing their (encrypted) user ID in a cookie, presumably).
I'm used to simply proxying through something like couchdb-python and a normal web server, but would like to know any best practices with respect to authenticating users in these kinds of CouchApps.
Edit: A year later, and this is now built into CouchDB. This video is a great demonstration. (Thanks Daniel!)
CouchDB has released a simple authentication api but has no in built authentication mechanisms as of yet. The simplest and easiest way to do this is to use an http proxy for authentication. However this has limitations on how much you can restrict access on a per document basis. When CouchDB gets some more support for built-in authentication modules then it should be easier.
If you want to try your hand at coding an authentication module then you can check out the source for the javascript security_validation tests in this file:
http://svn.apache.org/repos/asf/couchdb/trunk/share/www/script/couch_tests.js
and the default_authentication_handler in this file here:
http://svn.apache.org/repos/asf/couchdb/trunk/src/couchdb/couch_httpd.erl
that would get you started anyway.
This question has been around for a while (1.5 years!) and things have matured quite a bit since it was answered. Watch the video above, but it doesn't explain how to build it into your app. It looks like most of the answers are now found here: Security Features Overview and at the end of this document: CouchDB Security.
I want to log onto Stack Overflow using OpenID, but I thought I'd set up my own OpenID provider, just because it's harder :) How do you do this in Ubuntu?
Edit: Replacing 'server' with the correct term OpenID provider (Identity provider would also be correct according to wikipedia).
You might also look into setting up your own site as a delegate for another OpenID provider. That way, you can use your own custom URL, but not worry about security and maintenance as mentioned already. However, it's not very difficult, so it may not meet your criteria :)
As an example, you would add this snippet of HTML to the page at your desired OpenID URL if you are using ClaimID as the OpenID provider:
<link rel="openid.server" href="http://openid.claimid.com/server" />
<link rel="openid.delegate" href="http://openid.claimid.com/USERNAME" />
So when OpenID clients access your URL, they "redirect" themselves to the actual provider.
I've actually done this (set up my own server using phpMyID). It's very easy and works quite well. One thing that annoys me to no end is the use of HTML redirects instead of HTTP. I changed that manually, based on some information gotten in the phpMyID forum.
However, I have switched to myOpenId in the meantime. Rolling an own provider is fun and games but it just isn't secure! There are two issues:
More generally, you have to act on faith. phpMyID is great but it's developed in someone's spare time. There could be many undetected security holes in it – and there have been some, in the past. While this of course applies to all security-related software, I believe the problem is potentially more severe with software developed in spare time, especially since the code is far from perfect in my humble opinion.
Secondly, OpenID is highly susceptible to screen scraping and mock interfaces. It's just too easy for an attacker to emulate the phpMyID interface to obtain your credentials for another site. myOpenId offers two very important solutions to the problem.
The first is its use of a cookie-stored picture that is embedded in the login page. If anyone screen-scapes the myOpenId login page, this picture will be missing and the fake can easily be identified.
Secondly, myOpenId supports sign-in using strongly signed certificates that can be installed in the web browser.
I still have phpMyID set up as an alternative provider using Yadis but I wouldn't use it as a login on sites that I don't trust.
In any case, read Sam Ruby's tutorial!
I personnally used phpMyID just for StackOverflow. It's a simple two-files PHP script to put somewhere on a subdomain. Of course, it's not as easy as installing a .deb, but since OpenID relies completely on HTTP, I'm not sure it's advisable to install a self-contained server...
Take a look over at the Run your own identity server page. Community-ID looks to be the most promising so far.
I totally understand where you're coming from with this question. I already had a OpenID at www.myopenid.com but it feels a bit weird relying on a 3rd party for such an important login (a.k.a my permanent "home" on the internet).
Luckily, It is easy to move to using your own server as a openID server - in fact, it can be done with just two files with phpMyID.
Download "phpMyID-0.9.zip" from http://siege.org/projects/phpMyID/
Move it to your server and unzip it to view the README file which explains everything.
The zip has two files: MyID.config.php, MyID.php. I created a directory called <mydocumentroot>/OpenID and renamed MyID.config.php to index.php. This means my OpenID URL will be very cool: http://<mywebsite>/OpenID
Decide on a username and password and then create a hash of them using: echo -n '<myUserNam>:phpMyID:<myPassword>' | openssl md5
Open index.php in a text editor and add the username and password hash in the placeholder. Save it.
Test by browsing to http://<mywebsite>/OpenID/
Test ID is working using: http://www.openidenabled.com/resources/openid-test/checkup/
Rerefence info: http://www.wynia.org/wordpress/2007/01/15/setting-up-an-openid-with-php/ , http://siege.org/projects/phpMyID/ , https://blog.stackoverflow.com/2009/01/using-your-own-url-as-your-openid/
The above answers all seem to contains dead links.
This seems be a possible solution which is still working:
https://simpleid.org/
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
What are some guidelines for maintaining responsible session security with PHP? There's information all over the web and it's about time it all landed in one place!
There are a couple of things to do in order to keep your session secure:
Use SSL when authenticating users or performing sensitive operations.
Regenerate the session id whenever the security level changes (such as logging in). You can even regenerate the session id every request if you wish.
Have sessions time out
Don't use register globals
Store authentication details on the server. That is, don't send details such as username in the cookie.
Check the $_SERVER['HTTP_USER_AGENT']. This adds a small barrier to session hijacking. You can also check the IP address. But this causes problems for users that have changing IP address due to load balancing on multiple internet connections etc (which is the case in our environment here).
Lock down access to the sessions on the file system or use custom session handling
For sensitive operations consider requiring logged in users to provide their authenication details again
One guideline is to call session_regenerate_id every time a session's security level changes. This helps prevent session hijacking.
My two (or more) cents:
Trust no one
Filter input, escape output (cookie, session data are your input too)
Avoid XSS (keep your HTML well formed, take a look at PHPTAL or HTMLPurifier)
Defense in depth
Do not expose data
There is a tiny but good book on this topic: Essential PHP Security by Chris Shiflett.
Essential PHP Security http://shiflett.org/images/essential-php-security-small.png
On the home page of the book you will find some interesting code examples and sample chapters.
You may use technique mentioned above (IP & UserAgent), described here: How to avoid identity theft
I think one of the major problems (which is being addressed in PHP 6) is register_globals. Right now one of the standard methods used to avoid register_globals is to use the $_REQUEST, $_GET or $_POST arrays.
The "correct" way to do it (as of 5.2, although it's a little buggy there, but stable as of 6, which is coming soon) is through filters.
So instead of:
$username = $_POST["username"];
you would do:
$username = filter_input(INPUT_POST, 'username', FILTER_SANITIZE_STRING);
or even just:
$username = filter_input(INPUT_POST, 'username');
This session fixation paper has very good pointers where attack may come. See also session fixation page at Wikipedia.
Using IP address isn't really the best idea in my experience. For example; my office has two IP addresses that get used depending on load and we constantly run into issues using IP addresses.
Instead, I've opted for storing the sessions in a separate database for the domains on my servers. This way no one on the file system has access to that session info. This was really helpful with phpBB before 3.0 (they've since fixed this) but it's still a good idea I think.
This is pretty trivial and obvious, but be sure to session_destroy after every use. This can be difficult to implement if the user does not log out explicitly, so a timer can be set to do this.
Here is a good tutorial on setTimer() and clearTimer().
The main problem with PHP sessions and security (besides session hijacking) comes with what environment you are in. By default PHP stores the session data in a file in the OS's temp directory. Without any special thought or planning this is a world readable directory so all of your session information is public to anyone with access to the server.
As for maintaining sessions over multiple servers. At that point it would be better to switch PHP to user handled sessions where it calls your provided functions to CRUD (create, read, update, delete) the session data. At that point you could store the session information in a database or memcache like solution so that all application servers have access to the data.
Storing your own sessions may also be advantageous if you are on a shared server because it will let you store it in the database which you often times have more control over then the filesystem.
I set my sessions up like this-
on the log in page:
$_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR']);
(phrase defined on a config page)
then on the header that is throughout the rest of the site:
session_start();
if ($_SESSION['fingerprint'] != md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR'])) {
session_destroy();
header('Location: http://website login page/');
exit();
}
php.ini
session.cookie_httponly = 1
change session name from default PHPSESSID
eq Apache add header:
X-XSS-Protection 1
I would check both IP and User Agent to see if they change
if ($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']
|| $_SESSION['user_ip'] != $_SERVER['REMOTE_ADDR'])
{
//Something fishy is going on here?
}
If you you use session_set_save_handler() you can set your own session handler. For example you could store your sessions in the database. Refer to the php.net comments for examples of a database session handler.
DB sessions are also good if you have multiple servers otherwise if you are using file based sessions you would need to make sure that each webserver had access to the same filesystem to read/write the sessions.
You need to be sure the session data are safe. By looking at your php.ini or using phpinfo() you can find you session settings. _session.save_path_ tells you where they are saved.
Check the permission of the folder and of its parents. It shouldn't be public (/tmp) or be accessible by other websites on your shared server.
Assuming you still want to use php session, You can set php to use an other folder by changing _session.save_path_ or save the data in the database by changing _session.save_handler_ .
You might be able to set _session.save_path_ in your php.ini (some providers allow it) or for apache + mod_php, in a .htaccess file in your site root folder:
php_value session.save_path "/home/example.com/html/session". You can also set it at run time with _session_save_path()_ .
Check Chris Shiflett's tutorial or Zend_Session_SaveHandler_DbTable to set and alternative session handler.