I have a forum with >400 registered users. It's powered by vBulletin-4.0.4. I want to build up several websites with kohana-3.1, but keep existing forum users too. I will use seperate databases for each application (I want to keep apps as independent as possible).
So my solution is:
step 1. create special app users.mydomain.com where each user can register and update their details (birthdate/email/password). This app will catch all changes and write them to forum database and application databases.
step 2. modify default auth module to handle forum authentication. vBulletin uses algorithm: $hash=MD5(MD5($password)+$salt) for pass hashing.
Am I in the right direction? Is it OK?
Someone has already done this: Kohana vBulletin Bridge. You will need to contact the author of the module as the source code is no longer online. It wont be too difficult to upgrade it to 3 if you get it.
I haven't used vBulletin so I can't give you much advice on the subject, but you're right about the hashing algorithm. You'll also need to make sure your session is read and written as they are in vBulletin.
A quick search of vBulletin SSO to get you started.
Related
I need to create a pretty complex website for my class and before I started, I wanted to get some input from more experienced coders if I'm on the right track.
Basically, when I go to the url: I get a simple login page, when a user logs in - he can view his profile and make schedules / save etc...
I read a bit online and this is how I decided to proceed (please let me know if there is a simpler way or an already-made code for these):
1 . Access phpmyAdmin - create db
2 . Create a php function to access the db (add users etc...)
3 . use a login form with a php function on the main page and authenticate user/pass by accessing the db
4 . Use cookies to keep user logged in.
I also need to keep several lists for each user like:
classes = (comp232 , comp348 , comp352.....)
Which is the best way to do this for each user:
DB, txt file, List, Arrays?
The answer is 'depends'. However, when you had mentioned that you want to develop a 'complex website', it deserves to have Database roundtrip :) whereas all the other options you had mentioned would be simple enough for a stand alone application.
To answer your other main question, yes, there are already built in solutions which you can make use of, if you don't want to write the application on your own. However, you may need to evaluate thoroughly whether it fits your bill, else you may end up customising the application which is more or less half writing of the application by yourself.
If you want to write the application by your own, the PHP has got a built in APIs to achieve whatever you had mentioned. We have a great set of forums to get assistance wherever we are stuck.
Has anyone made any headway with coming up with a single sign on solution
with Domain access to date for Drupal 7? I've been looking closely at two old
modules, one no longer maintained (SSO for D6) and one still maintained (CAS). I've also read that SAML might be a key to unlocking this, but am uncertain.
Facebook's FBConnect might be another option too or another way could be integrating OpenID from what I've read, and experienced on StackOverflow's sub sites.
I know that OpenID can do this since we are logged into all of *Overflows sub sites at the same time using one login. The question is how does it cross DNS servers? Does it handshake with one half of a matching hash? I cannot find any documentation on this, so am at a loss.
So, are there any solutions that are known to date, or information on what to start
looking into? I think I've made a good point at the possibilities. I read this thread, Domain Access SSO but am uncertain to what version it pertains to (Drupal. DA, SSO or otherwise). It looks like the "Solution" is to create a master table set with users and permissions, then share those across the domains? How might this work if there are already multiple sites created under Domain Access? Would you clone and rebuild the entire installation, or would you need to start from scratch? It really raises more questions than answers. I contacted the author with no response, so the questions still stand.
Any opinions out there on the who what or why would be greatly appreciated, I just need a start point to get the ball rolling. Thanks everyone.
I'm the author of the Domain Access SSO article mentioned in the original question. I don't recall being contacted about it, but then again I recently learned that my "contact" page on bleen.net hasn't been working in a while... but anyway, here is a bit of info:
That post referred to Drupal 6, SSO Module 6.x-1.0-rc1, and Domain Access module 6.x-2.0 (I think). That solution basically revolves around creating two separate drupal installs, one the master and one the client (there can be multiple clients). Basically, what happens is the necessary user tables for all teh clients are pointed instead to the master. In doing so, the master becomes (essentially) a shell site that does nothing but hold and verify user data.
Hope that makes sense and/or helps... to be honest i havent looked at that code in a long while now.
SAML is a good option. Check this module to integrate it with drupal:
http://drupal.org/project/simplesamlphp_auth
If you need a demo with this plugin working check this.
I am building an GAE app that allows users to share documents over different contexts. Nothing too fancy.
I want to use Gdata in such a way that it is the app that owns the documents, and not the users. This way, I shouldn't need any kind of tokens --one would think.
This is the main idea:
App user creates doc --> App creates doc and owns it --> user can RUD & share the doc
Is there any recommended way to authenticate using just a hard coded user & password?
The ClientLogin, up to now, seems to be the way to go.
http://code.google.com/apis/gdata/docs/auth/clientlogin.html
But I still have some doubts about the following:
Am I putting myself in a scenario of possible restrictions over other alternatives?
Is really ClientLogin the best way to go?
Could really use advice from others' experience here. Procrastination is killing me.
Cheers,
A.
If this is a personal project, and you've only got a very small group of users, the design might be OK.
One really good reason to use OAuth is that you won't need to store the account password somewhere. Instead you'll be able to implement a simple 'setup' process to get and store an access token. OAuth is also nice since you'll be able to restrict the access scope.
However, I must say, I find your question very vague -- so more specific answers are difficult.
I'm asking your opinions about my next project..
I'm planning to make website which offers services where all users would be have own subdomain (user.mydomain.com) and own website.
First I was thinking to really make real subdomain, generating automatically website code into their folder, creating own database etc..
Question #1: When I need some information from all subdomains databases in my main page (mydomain.com), how can I fetch those?
Would it be better way just use one database and dynamic code what all users are using but then re-write address like it would be subdomain (mydomain.com?user=myuser -> myuser.mydomain.com)
If someone have experience with something like what I was planning, would be nice to have tips and tricks do it right! :)
Thanks!
It will be alot of less code to maintain in you have one common codebase for all users, that just reads the domain name and uses that information.
Imagine that you discover an error in the code that was generated for one of the subdomains.
Either you would have one place to correct, or you would have 1 place + the number of users to correct.
You'll probably want all of the subdomains to point to the same codebase and treat the subdomain as an argument that is pulled out and identifies which instance of this application it is. You'll need a table in your db that will store information about each instance and then user accounts, user data, etc will all be tied back to a specific instance.
When I was setting up an account with gmail few years back (probably this is still a case, haven't check) I've noticed that system doesn't allow to register common terms, nouns as username, it seemed that it used a sort of dictionary for screening. I would like to implement similar feature in my app, anyone have idea how to tackle this? App is written in PHP but understand I'll have to hook it up with online service.
Thanks
Wordpress MU has such feature too, you fill a list of possible usernames that you want to avoid and they become unavailable for users. You can check its source to get their approach...
Sinan.
Well the API will vary from service to service so I'd suggest you find one, look at their developer docs and then if you have a question ask it here.