Author Topic: local standalone without openid? (Read 8676 times)

markum · May 09, 2009, 01:28:10 pm

Hi,

I have just installed the standalone version of civicrm on my laptop. The problem of having a local installation is that I am travelling sometimes and therefore an openid login is not always possible. Therefore I would like to know if it is possible to replace OpenID with a normal username/password login. I guess an alternative would be to run a local openid-server, but my since civicrm is already very slow I would like to avoid having another service running. So is there another way of doing this?

Greetings,

Markum

Donald Lobo · May 09, 2009, 11:02:34 pm

Enhancing the functionality to allow folks to use a local registration method instead of openID is potentially a good step. There have been a few requests for this. A contribution to make this happen will be welcomed by a few folks in the standalone community

lobo

mr206 · July 02, 2009, 08:49:15 am

Unfortunately, I don't have a contribution to make, but I would like to add my voice to those who would like another option, other than openID.

(I find openID *excellent* for staff, board, and other people associated with the organization, however, I fear it might just be too high a hurdle for people who are not, e.g. donors.)

Donald Lobo · July 02, 2009, 09:06:59 am

maybe you could organize a group of folks who want another option and raise the funds and sponsor the development. However if needing another option is key, then not very sure why folks dont use a CMS which gives you that option (and also a lot more)

lobo

mr206 · July 03, 2009, 08:59:18 am

That's a complicated question, for me at least. I found CiviCRM when I started my new job, which was busily tracking client relations with a near-endless series of increasingly redundant excel spreadsheets. I was in IT in the mid-nineties, but have been out of it since 1998, which is, um, kindof a long time in IT-ville. So, I've never used Drupal *or* Joomla before, and indeed, hadn't heard of them until I read of CiviCRM. When looking at the learning curve/ overhead of learning a new program (CiviCRM) vs what seemed to amount to *two* new programs CiviCRM *and* Drupal or Joomla, it seemed that the standalone version made more sense. I didn't find anything that suggested that the standalone version had less functionality. It seemed to me that the advantage of the Drupal or Joomla versions was for people already administering a website with one of those tools. The website of my organization is not managed by a tool, well, frankly it's not managed at all, but that's a lower priority for me than getting the office-client admin stuff up and running.

So that's a long answer to a question you probably thought was rhetorical. I think that in retrospect, standalone is conceived of as a last-resort product and the other two as the "real" versions. This is just my hypothesis. If I had known, I might have undertaken to learn one of the others instead. Of course, I can't find any logic to whether Drupal or Joomla is better or what either is better for, so that also limits my desire to jump into those waters.

cap10morgan · July 06, 2009, 03:32:16 pm

So there are a few issues to address here. I'll try to hit them all, but let me know if I miss any.

1. Problem: You want to be able to login to a CiviCRM standalone instance w/o having an Internet connection which would be required to verify your OpenID. Potential solutions: 1. Run a local OpenID provider separate from CiviCRM; 2. Implement a non-OpenID login method for this use case (and possibly others); 3. Make CiviCRM itself an OpenID provider. I personally prefer #3 as the long-term solution here, especially since it solves many other use cases too and is a natural fit for a CRM. Since it already holds lots of data on people, it would be nice if it could (optionally) turn those records into OpenIDs. If we go this route, then my goal would be to make the interface behave just like a traditional login system. So you'd just have a username and a password and they would be verified locally with no Internet connection required. Behind the scenes CiviCRM would treat this as a local OpenID, but the user need not know or care about that until the day comes that she wants to use it to authenticate on a different site, which she can do by using "http://username.civicrmsite.org/" as her OpenID (or something along those lines). What do you think?

2. Problem: OpenID is inappropriate for some users (with the implication that a CiviCRM-specific login would be better). Response: I don't think this is right. The main problem with OpenID as it is currently implemented in CiviCRM standalone, aside from the disconnected login issue, is that it doesn't make it apparent that you most likely already have one. A login you already have is certainly preferable to having to register for yet another login on yet another site you may or may not ever re-visit. CiviCRM 2.3 will have a provider selector widget that pops up and makes it much more apparent to users that they probably already have an OpenID. So hopefully this point of confusion will go away.

3. Problem: Standalone is the most limited version of CiviCRM. Response: Yes and no. It's the most recently developed version of CiviCRM, but it has most if not all of the functionality of CiviCRM *as a CRM*. When we implemented standalone, it wasn't so much a matter of exposing CiviCRM features in standalone one by one as it was making the front-end display system work w/o a CMS and then everything else was just there. Having said that, since there is no CMS involved, there is not much out-of-the-box CMS integration happening. So if having your CRM and your website work pretty closely together (for example, to display an event reg. form and a list of those already attending on your website which posts to/reads from your CRM) is important to you, then choosing CiviCRM+Drupal or CiviCRM+Joomla! might be a better choice than CiviCRM standalone. However, if you need it to work with a different CMS and/or don't have those requirements, then yes, standalone is a simpler and more appropriate choice. In my day job, I integrate our CMS (WebGUI: open source mod-perl CMS) with CiviCRM via the REST API. So there are lots of ways to do that depending on your resources and requirements.

Does that help?

BadPenguin · August 21, 2009, 08:57:49 pm

I have installed and administered various forums and cms packages over the years. I write and maintain portal systems and sundry lamp based specialty applications professionally. I must say, deploying a system that relies on a 3rd party, network connected authentication implementation seems a bit odd. I can think of many reasons why using openid for authentication is a very bad idea, and quite frankly, I cannot think of any compelling reasons to use it. Just out of curiosity, why does CiviCRM use openid for authentication? Does CiviCRM use openid when it is implemented via joomla/drupal?

I am currently attempting to deploy a standalone CiviCRM implementation for a non-profit. Our primary facility has no internet connection. Installing and using CiviCRM there, requiring openid for authentication, is just not realistic. I have managed to set up a "single-user" openid package called phpMyId for the 5 users who will actually need to logon to CiviCRM to use it.

Why shouldn't it be used?

To use CiviCRM, users have to create accounts with unknown, untrusted 3rd parties.
Asking users who have never created an openid identity to enter an identity url is extremely user unfriendly. 99.99% of all web based applications use the old fashioned approach of asking for a username and password.
If you have no network connection to the identity provider, you can't use the application.
You have no idea who the identity provider is, how secure their networks are, how secure their implementation is, how trustworthy their employees are, and if they will even still be in business next year. You have absolutely no control over your own security, nor can you realistically determine/mitigate risk. Even if you know the identity provider for your own identity is secure, if you allow users to login with other providers, you have no idea how secure their providers are.
The openid code requires various math libraries, http digest authentication, random number generation, extraneous cookies, etc... Authenticating users against a database table is as simple as "select x from table where password=md5($user_provided_password) limit 1".

Why should it be used?

Some day openid might be more widely used.
?

Now that I am done ranting about that, can someone point me in the general direction of where the code is within CiviCRM that ties into openid? I might want to take a crack at creating some sort of local authentication module... I have no idea how deeply the openid authentication is embedded.

Donald Lobo · August 22, 2009, 05:52:51 am

most of the files in the standalone directory are involved with the authentication process

standalone was a sponsored project. the folks who paid for it had decided to use OpenID as their authentication scheme

If you want a simple table based auth scheme, any specific reason you are not using Drupal or Joomla version of CiviCRM?

lobo

BadPenguin · August 22, 2009, 06:23:51 am

Quote from: Donald Lobo on August 22, 2009, 05:52:51 am

most of the files in the standalone directory are involved with the authentication process

standalone was a sponsored project. the folks who paid for it had decided to use OpenID as their authentication scheme

If you want a simple table based auth scheme, any specific reason you are not using Drupal or Joomla version of CiviCRM?

lobo

We already have a cms and have absolutely no desire to use another. We need a CRM for non-profits, not a CMS... Our current CMS, if you could call it that, was written by a volunteer (me) and is very specific to our needs. It has worked flawlessly for many years and has rarely needed any updates or tweaking whatsoever. I don't know about other non-profits, but ours does not have any paid IT staff, it is run entirely by volunteers. Attempting to use a CMS like drupal or joomla, which require a fairly high learning curve and frequent updates/tweaking/administering, is not a very realistic option. The volunteers come and go, often. The organization needs something simple, rarely needing maintenance/updates/patches. Their software needs to be installed, configured, and other than having data being entered by the volunteers, forgotten.

But you may have answered my question, I assume from your response that the Drupal/Joomla versions use their respective CRMs for authentication.

Donald Lobo · August 22, 2009, 06:54:13 am

rather than trying to hack the code, i would just use civicrm on drupal. You dont have to use the other features of drupal, just the user management part

in general most open source software needs to be upgraded on a regular basis to keep up with security releases / bug fixes etc. I suspect if u want to install and forget about it, it might not be a great match

lobo

BadPenguin · August 22, 2009, 07:06:44 am

Quote from: Donald Lobo on August 22, 2009, 06:54:13 am

rather than trying to hack the code, i would just use civicrm on drupal. You dont have to use the other features of drupal, just the user management part

in general most open source software needs to be upgraded on a regular basis to keep up with security releases / bug fixes etc. I suspect if u want to install and forget about it, it might not be a great match

I don't mind maintaining/updating CiviCRM, but I would mind having to install, maintain, and update something such as drupal or joomla every few (days/weeks/months). I mean really, is CiviCRM a cms module, or a CRM? The standalone version appears to fit our needs. I don't want to have to update it every time a vulnerabilities/features appear in an upstream CMS that is not even needed by us. Maintaining and administering a standalone CRM -vs- maintaining/administering drupal/joomla and a CRM are two very different animals. I can't imagine how the developers deal with the nightmare of maintaining compatibility of a major app with two different CMS's, my hat is off to them.

Donald Lobo · August 22, 2009, 07:33:46 am

its not as hard as you think

(yes its a bit painful sometime)

However the advantages of a CRM integrated with a CMS is probably CiviCRM's biggest strength (IMO). The integration with drupal permissioning, views and other modules really makes the whole package a whole lot more compelling than just a CRM. my 2 cents ...

lobo

BadPenguin · August 22, 2009, 08:07:42 am

Quote from: Donald Lobo on August 22, 2009, 07:33:46 am

However the advantages of a CRM integrated with a CMS is probably CiviCRM's biggest strength (IMO). The integration with drupal permissioning, views and other modules really makes the whole package a whole lot more compelling than just a CRM. my 2 cents ...

Heh heh, we will just have to agree to disagree

If I were looking for a CMS and a CRM, or already using drupal or joomla, I would probably be inclined to agree with you. But unfortunately, we are looking for a CRM geared towards non-profits, not a CMS, we don't need all of that CMS bling... What makes it compelling to us it's usefulness as a CRM. When needing to use a CiviCRM as a CRM instead of a CMS module/add-on, the CMS integration becomes a hindrance to adoption.

Apparently the "standalone" version was an after-thought, and really isn't standalone, since it requires the use of 3rd party providers to even authenticate to it.

But hey, I'll quit whining, this is what open source is all about. Heh heh. I have an itch and I am going to try to scratch it. It shouldn't be too terribly difficult to implement a password field in the user table to authenticate against... What might be hairy is figuring out how to implement a config option to allow a "local authentication" mode so the functionality can be toggled in the admin options, then adding fields in the add/edit contact forms, login forms, etc... Sounds fun

xavier · August 22, 2009, 10:20:41 am

Quote from: BadPenguin on August 22, 2009, 08:07:42 am

But hey, I'll quit whining, this is what open source is all about.

Have to disagree, open source is about installing/patching/upgrade/patch again

Quote from: BadPenguin on August 22, 2009, 08:07:42 am

Heh heh. I have an itch and I am going to try to scratch it. It shouldn't be too terribly difficult to implement a password field in the user table to authenticate against... What might be hairy is figuring out how to implement a config option to allow a "local authentication" mode so the functionality can be toggled in the admin options, then adding fields in the add/edit contact forms, login forms, etc... Sounds fun

Unless you plan to provide a password to the vast majority of users, I'd suggest to have a separate user table (as opposed as adding a pwd field in the civicrm_contact).

Also, no need to have a web interface to choose the local auth, do like for the 3 existing, from a config value in a file.

Let us know how it goes.

X+

BadPenguin · August 22, 2009, 02:32:33 pm

Quote from: xavier on August 22, 2009, 10:20:41 am

Unless you plan to provide a password to the vast majority of users, I'd suggest to have a separate user table (as opposed as adding a pwd field in the civicrm_contact).

I was thinking along the lines of adding a checkbox next to the "allow openid authentication" - like "allow local authentication". That way it can work alongside openid authentication.

I am seeing a couple of columns already in the civicrm_contacts table, both would be adequate for a 32 character md5 hashed password, the hash and api_key columns. I can't quite figure out what those are currently used for though.

CiviCRM Community Forums (archive)

News:

Author Topic: local standalone without openid? (Read 8676 times)

markum

local standalone without openid?

Donald Lobo

Re: local standalone without openid?

mr206

Re: local standalone without openid?

Donald Lobo

Re: local standalone without openid?

mr206

Re: local standalone without openid?

cap10morgan

Re: local standalone without openid?

BadPenguin

Re: local standalone without openid?

Donald Lobo

Re: local standalone without openid?

BadPenguin

Re: local standalone without openid?

Donald Lobo

Re: local standalone without openid?

BadPenguin

Re: local standalone without openid?

Donald Lobo

Re: local standalone without openid?

BadPenguin

Re: local standalone without openid?

xavier

Re: local standalone without openid?

BadPenguin

Re: local standalone without openid?