Loading Profile...
Use helpcenter with userdata from our service, possible?
Is it possible to post to help center without a getsatisfaction account?
At www.secondbrain.com, we are working on moving our support issues to the get satisfaction helpcenter. The helpcenter is hosted at a mediatemple account, and the main service is hosted by rackspace. Is it possible to allow users to post in the help center, with their credentials from secondbrain, or do they need a separate getsatisfaction account?
Get satisfaction is quite awesome, so I have no problems with promoting the benefits from having an account here, but it would be nice to avoid the need of another registration just to get help...
At www.secondbrain.com, we are working on moving our support issues to the get satisfaction helpcenter. The helpcenter is hosted at a mediatemple account, and the main service is hosted by rackspace. Is it possible to allow users to post in the help center, with their credentials from secondbrain, or do they need a separate getsatisfaction account?
Get satisfaction is quite awesome, so I have no problems with promoting the benefits from having an account here, but it would be nice to avoid the need of another registration just to get help...
I’m uncertain
2
people have this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
The best answer from the company
-
Hi Audun,
There's a couple of different possibilities for solving the account problem. First of all, before I talk about those options... yes, your users will have to have an account on GSFN in some shape or form.
So, as far as options, we've thought about two methods that let you expose your user accounts more simply to Satisfaction. First, we can enable your API key to create user accounts through the API. You would then need to keep track of mappings between GSFN accounts and accounts from your service by, for example, modifying your accounts table to keep an Access token and secret attached to that user account. To implement something like this, you would basically need to rewrite the whole login and posting process for helpcenter with code tied into your particular organization. I can go into more technical details if you would like, but I just wanted to give you a general idea of the effort involved.
The second option, which I am working on implementing right now (it's not quite finished yet) leverages OpenID. Basically, if you can make your service compatible with the OpenID standard as an OpenID provider you will then be able to log users into help center using your own login form (Or bypass it directly if they are already logged in). When people ask the question you are asking, I usually push them towards this solution because it is much less ad-hoc than the OAuth route, but more importantly it gives your users more control. Basically, you would rewrite the login action for helpcenter to pass along an openid to the API authorization page. Get Satisfaction would then complete the OpenID process, redirecting back into your application per the OpenID spec where you can present the login form if necessary. The nice thing about this is that we don't need to generate a random password for user accounts created through this method.
As you can see, both methods require a lot of work on your end to integrate; it is by no means a turn-key solution. That's the main reason I steer people towards just using Get Satisfaction proper. The cost of using GSFN on your part follows this path: GSFN.com -> Helpcenter -> OpenID -> OAuth account creation.
If you are serious about integrating your user account data into GSFN and your Help center, we can talk about it more: each of these integrations will no doubt require some form of collaboration between our two organizations. There's too many moving parts, it could be very frustrating on your end without it.
Hope that helps, and let me know if you have any questions on each of the approaches,
Scott
3 people say
this answers the question
-
Inappropriate?Hmmm... It seems like you'll need a GetSatisfaction account to post, wether it is the help center or directly to get satisfaction. My question (and hopefully the final one) would then be:
Would it be possible to push new SecondBrain accounts into GetSatisfaction so users don't need one more signup to post help requests?
I REALLY like GetSatisfaction (compared to email, this has the potential to reduce the workload a LOT!), so it would make my day if this is possible
I’m Hopeful
-
Inappropriate?Hi Audun,
There's a couple of different possibilities for solving the account problem. First of all, before I talk about those options... yes, your users will have to have an account on GSFN in some shape or form.
So, as far as options, we've thought about two methods that let you expose your user accounts more simply to Satisfaction. First, we can enable your API key to create user accounts through the API. You would then need to keep track of mappings between GSFN accounts and accounts from your service by, for example, modifying your accounts table to keep an Access token and secret attached to that user account. To implement something like this, you would basically need to rewrite the whole login and posting process for helpcenter with code tied into your particular organization. I can go into more technical details if you would like, but I just wanted to give you a general idea of the effort involved.
The second option, which I am working on implementing right now (it's not quite finished yet) leverages OpenID. Basically, if you can make your service compatible with the OpenID standard as an OpenID provider you will then be able to log users into help center using your own login form (Or bypass it directly if they are already logged in). When people ask the question you are asking, I usually push them towards this solution because it is much less ad-hoc than the OAuth route, but more importantly it gives your users more control. Basically, you would rewrite the login action for helpcenter to pass along an openid to the API authorization page. Get Satisfaction would then complete the OpenID process, redirecting back into your application per the OpenID spec where you can present the login form if necessary. The nice thing about this is that we don't need to generate a random password for user accounts created through this method.
As you can see, both methods require a lot of work on your end to integrate; it is by no means a turn-key solution. That's the main reason I steer people towards just using Get Satisfaction proper. The cost of using GSFN on your part follows this path: GSFN.com -> Helpcenter -> OpenID -> OAuth account creation.
If you are serious about integrating your user account data into GSFN and your Help center, we can talk about it more: each of these integrations will no doubt require some form of collaboration between our two organizations. There's too many moving parts, it could be very frustrating on your end without it.
Hope that helps, and let me know if you have any questions on each of the approaches,
Scott
3 people say
this answers the question
-
Inappropriate?Hi Scott!
As usual: Excellent service from GSFN.
I'll give your options some more thought, but as of now, we are tipping towards adding the helpcenter as an option together with our email-system, instead of removing the email system completely.
Even tough, GSFN is one of the best solutions I've seen. The support you give is awesome! Thanks!
I’m thankful
-
Inappropriate?Audun,
Thanks for the kind words!
I agree with your choice to not ditch the email entirely. I don't think that should ever happen since some percentage of your users will insist on email contact, and by making it hard for them to find your email or contact you in private will just frustrate them. The trick is to learn how to funnel your users to the helpcenter while still making the email channel available. You want to reduce your email traffic through incentive rather than restriction. It takes a little bit of experimentation and refinement, I think.
Personally, I'm a fan of exposing the user to your direct contact info after they've seen the option to post using helpcenter. For example, you could put your email underneath the "Ask a question" box so it reads "Ask us a question [TextBox] or send us an email at foo@bar.com". I haven't done any studies to see if that is actually effective, but my that's what my intuition tells me could work. Likewise, having it in the footer like we already do it important also.
-Scott -
Inappropriate?Scott,
Is there a possibility of GSFN ever implementing a feature that would maybe allow us to give GSFN access to our customer tables which hold usernames and passwords so that you guys could import them into your system thus eliminating our users to register with GSFN and at the same time eliminating the need for us to re-write the helpcenter code?
Or is there a possibility for us to run some API calls that would create user accounts (using a username and password entered by the user) whenever users create accounts on our websites and that way you would store the user information without us having to map any of the details between our website and GSFN?
I’m just wondering
-
Inappropriate?Marat,
Firstly, Thanks for all the great feedback over the last day; it has been immensely helpful.
So, in the way you describe it, no. To be frank, it would be wildly irresponsible if you are storing passwords in your database in a form where I could pull your customers' passwords. One of the cardinal rules is never store plain text passwords in your database: Any hack and your attacker now has access to each of your customers password.
Assuming that you are actually storing your passwords in a secure manner, for example using individual salts and a one-way cryptographic hash, implementing what you describe would mean that at GSFN we would need to re-write you authentication algorithm to fit with those values. It wouldn't be economical in any way.
That's why I push the OpenID provider route. It let's us leverage your authentication system while letting you keep control of it. It would be effectively as you requested, but it would require work on your side rather than mine :)
---
We do have methods in the API to create user accounts, although I restrict this ability to only a certain subset of API keys whom I have confirmed are going to be responsible with the power. I certainly don't want spammers to have that ability.
The catch here is that there is no way to specify a password: A default random password always generated for the created user, and is sent to the new user in an email message. This is so that the user whose account you created for them has the ultimate control over their presence in GSFN.
-Scott
-
Inappropriate?Scott,
Thanks for all your help mate. Firstly I'm only in the process of creating my website, so it's not up and running yet :)
Secondly because my website will be mainly for Australian users I don't think OpenID will be used/known that much. I believe that in the future if I was able to receive API key which enabled me to make user accounts without the password I think I could let my users know that we will be using GSFN for our help center so that when they receive their emails from GSFN they would know exactly what's going on.
Thanks
I’m happy with Scott's answer
EMPLOYEE
