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.
Related
I love CakePHP, but cannot wrap my head around the ACL/Auth subject. Everything else comes together nicely, but when it comes to this, I am lost. On top of it, I cannot finish my application if this is not solved. Therefore, I desperately need your help.
Things to note:
I have tried a few of the plugins available, but to no avail.
I have used tutorials online as well as the latest CakePHP book by Mariano, with no success.
I have tried on my own, also to no avail
Why is it so hard to get this accomplished?
These are my questions:
Is there any other way to handle Access Rights in a CakePHP application with Multiple Admin, users, etc?
For the possibility that ACL is the only/best way, how else could I approach this?
What could I possibly be doing wrong?
As you say that you have already tried a few of the available plugins, you have maybe already tried my own one: http://www.alaxos.net/blaxos/pages/view/plugin_acl It is mainly a graphical interface that allows to set the ACL permissions when they are used to grant/deny access to actions.
My point here is that in addition to the plugin itself, I made available a very simple sample application http://www.alaxos.net/blaxos/pages/view/demo_plugins that uses this plugin. It may help you if you install it and look at the code, as the application has some public parts, and some parts protected by the ACLComponent.
This is one of the pains in Cake, the complexity of ACL..
Is there any other way? Well, yes. Yes, in the sense that you can cook up your own access rights management, and simply go around the cake's ACL implementation. For example, you could have a role based ACL where roles would be pretty much a fixed list. This can be accomplished in many ways, one of which was demonstrated with DarkAuth.
Further more, don't try to fit your app into the cake's ACL scheme if it doesn't suit you. Bake your own, cake offers you the option of plugging in your own objects for auth/ACL stuff, so use it!
But do note that any feature-rich ACL system you want to create yourself might end up looking much like cake's ACL..so first decide exactly what you need, and then look for a way to do it.
In any case, good luck!
I just recently wrote the probably most simple Auth - I called it "Tiny":
http://www.dereuromark.de/2011/12/18/tinyauth-the-fastest-and-easiest-authorization-for-cake2/
It should be just about what you need.
It does need the roles to be present in the Session Auth, though and that you manage user roles yourself.
So you might have to add this to your login method if you want to use multi role Auth.
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.
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.
I want to access facebook's database.
I want to have some SQL-like access, let's like this:
"select name from facebook-big-database-table where location='France' and city='Paris' and age
between 30 and 40;"
But, it need not to be SQL, PHP or JAVA would also be nice to use to me.
Does anybody know where to start?
To be honest, I got a little bit lost in all the tutorials Facebook offers.
Is it the so called "Connect" program which offers me what I want or something different?
Facebook does have a bunch of API's, one of which actually looks like SQL. They call it FQL. Check it out here. Maybe it can help you some part of the way at least.
Note that it won't give you raw access to the underlying tables. But still, better than nothing I guess.
Facebook isn't going to let you mine their database in that way. Not possible.
You wont be able to access facebook's database. The most you'd be able to do is to get information of users who previously have consented your application to access their data.
Therefore answering your question, what you want can't be done, period.