Skip to content
This repository has been archived by the owner on Aug 16, 2023. It is now read-only.

Would be a lot better if you create a SimpleAuthUser #2

Closed
akashkamboj opened this issue Nov 10, 2013 · 9 comments
Closed

Would be a lot better if you create a SimpleAuthUser #2

akashkamboj opened this issue Nov 10, 2013 · 9 comments

Comments

@akashkamboj
Copy link

@calebd Also it would be a lot better that you create a NSObject for SimpleAuthUser and fill the necessary properties in that. So in case someone requires a Facebook Access Token, expires at etc. it can be filled in the SimpleAuthUser class. What do you think?

@calebd
Copy link
Owner

calebd commented Nov 11, 2013

I thought about doing that but the responses from every possible provider are very different so I couldn't cover them all from SimpleAuth itself, given that all providers will be their own repositories. The decentralized design makes this difficult.

@akashkamboj
Copy link
Author

I thought about it so. But then why not we have a result block of:

typedef void (^SimpleAuthUserResultHandler)(SimpleAuthUser *user, NSError *error);

and user will have 3-4 properties:

  1. access_token (oauth_token) - NSString
  2. access_secret - NSString
  3. authData (NSMutableDictionary) - for everything else

by using that result handler block you don't have to change the result handler blocks in future. you can just add remove properties of SimpleAuthUser, once most of the providers are implemented. I would advise this approach, because I see many repositories that can't implement the parameters, blocks in future releases, bcoz they were using different patterns in previous releases.

@calebd
Copy link
Owner

calebd commented Nov 11, 2013

The problem is that Facebook uses a token and an expiration date, Twitter uses a token and a secret, Instagram uses just a token, ... Most providers return completely different data. Some might have an email and password and no token at all. Trying to come up with a single concrete class for every provider to use would be messy I think. To put it another way, there isn't anything that a dictionary can't store that a class can, which I think is the best level of abstraction between a provider and an API consumer.

@akashkamboj
Copy link
Author

ok understood. but at least there should be some similar pattern for dictionary. Take a look at omniauth-facebook hash at https://github.com/mkdynamic/omniauth-facebook#auth-hash. Because in current SimpleAuth-Facebook you can't get a oauth_token. I would say that return a dictionary but filling it manually based on a common pattern.

@calebd
Copy link
Owner

calebd commented Nov 11, 2013

Yeah I have an open issue on the Facebook provider where it currently doesn't return the token as it should.

@calebd
Copy link
Owner

calebd commented Nov 14, 2013

I merged that PR on the Facebook provider. You ok if I close this issue now?

@akashkamboj
Copy link
Author

Well in my project I am building a dictionary based on OmniAuth pattern, if you think it's useful then you can go something along this way. or you can close the issue.

- (NSMutableDictionary *)buildHashWithResponseObject:(id)responseObject account:(ACAccount *)account {
    NSMutableDictionary *infoDictionary = [NSMutableDictionary dictionary];
    [infoDictionary setObject:responseObject[@"username"] forKey:@"nickname"];
    [infoDictionary setObject:responseObject[@"email"] forKey:@"email"];
    [infoDictionary setObject:responseObject[@"name"] forKey:@"name"];
    [infoDictionary setObject:responseObject[@"first_name"] forKey:@"first_name"];
    [infoDictionary setObject:responseObject[@"last_name"] forKey:@"last_name"];
    [infoDictionary setObject:[NSString stringWithFormat:@"https://graph.facebook.com/%@/picture?type=large", responseObject[@"id"]] forKey:@"image"];
    //TODO - add urls

    NSMutableDictionary *credentialsDictionary = [NSMutableDictionary dictionary];
    [credentialsDictionary setObject:account.credential.oauthToken forKey:@"token"];

    //TODO - research on expiration
    [credentialsDictionary setObject:@"0" forKey:@"expires_at"];
    [credentialsDictionary setObject:@"0" forKey:@"expires"];

    NSMutableDictionary *extraDictionary = [NSMutableDictionary dictionary];
    [extraDictionary setObject:responseObject forKey:@"raw_info"];

    NSMutableDictionary *dictionary = [NSMutableDictionary dictionary];
    [dictionary setObject:@"facebook" forKey:@"provider"];
    [dictionary setObject:responseObject[@"id"] forKey:@"uid"];
    [dictionary setObject:infoDictionary forKey:@"info"];
    [dictionary setObject:credentialsDictionary forKey:@"credentials"];
    [dictionary setObject:extraDictionary forKey:@"extra"];

    return dictionary;
}

and in authorize

- (void)authorizeWithSystemAccount:(ACAccount *)account completion:(SimpleAuthResultHandler)completion {
    [self facebookAccountWithSystemAccount:account completion:^(NSHTTPURLResponse *response, id responseObject, NSError *error) {
        if (!responseObject) {
            // TODO - Build a better Error
            completion(nil, error);
            return;
        }

        NSMutableDictionary *authHash = [self buildHashWithResponseObject:responseObject account:account];
        completion(authHash, nil);
    }];
}

Well I am doing this becuase my app is in Ruby on Rails and I am using omniauth, so my Website and iOS auth share same pattern. It's totally upto you.

@akashkamboj
Copy link
Author

BTW same goes for twitter, because in current SimpleAuth-Twitter, the only information it's returning is tokens, screen_name and user_id. I needed more information like Full Name, Picture etc. So made another request and fill the dictionary based on that.

@calebd
Copy link
Owner

calebd commented Nov 15, 2013

Ok I totally see what you're going for now. I'll start working on this now, beginning with Facebook. I'll also add profile fetching to the Twitter provider.

I also created a google provider repo for you and gave you push access. Let me know if you need anything else there!

@calebd calebd closed this as completed Jan 16, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants