I'm trying to use the various examples as a means to write my own, but I don't fully understand what is happening. Maybe someone can offer some insight.
I thought I needed to implement some URL that is listening for a callback from the 3rd party auth request, but when I look at the github implementation, for example, I see
public const string CallbackPath = "/signin-github";
and I don't see anything that is listening for that.
The callback endpoint is managed by the OAuth2 generic handler:
https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNetCore.Authentication/RemoteAuthenticationHandler.cs#L40-L55
https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNetCore.Authentication.OAuth/OAuthHandler.cs#L45
You don't need to (and shouldn't) create your own route.
Related
In my ember-cli app I use a token based approach to communicate with a secured REST interface on the server side. As tokens expire after some time, I would like to realize the following behaviour:
As soon as the client tries to access the REST service with an expired token, I would like the user to be redirected to the login screen.
Right now I use the 'catch' function on the store's find method while fetching data in the route's model callback. This works quite well. As a matter of fact, there are more REST invocations than the ones that refer to the model store.
What would be the best practice to deal with this situation? In what place should I implement the (exception) handling? As this seems to be a crosscutting concern, I'd like to implement it in a central place.
I prefer to follow an optimistic approach, thus not checking the validity of the token on each and every transition. It will be sufficient if the redirect will take place the moment the application tries to communicate with the REST interface (ie as soon as it gets the error message from the server).
Thanks
You may want to consider the global jquery hooks so you can respond to an Auth fail uniformly. See:
http://api.jquery.com/category/ajax/global-ajax-event-handlers/
It's up to you if you want to set window.location or lookup your application controller and use transitionToRoute() for switching to the login route. Make sure that if you use Ember functions to put your code in an Ember.run.once() from your jquery hook function so it occurs on the Ember run loop.
You could also consider using Ember SimpleAuth (which kind of locks you into its paradigm) or even better and a safer long term priposal IMO, doing it from scratch by first following these tutorials:
- http://coderberry.me/blog/2013/07/08/authentication-with-emberjs-part-1/
- http://coderberry.me/blog/2013/07/08/authentication-with-emberjs-part-2/
And then this which is newer and incorporates the above tutorials:
- http://webcloud.info/blog/2014/04/07/emberjs-authentication-the-right-way-javascript-version/
I have one class called OAuthLogin that supports the login of a user via OAuth. The website supports also a "traditional" login process, without OAuth. The two flows share a lot of code, where I need to differentiate them sometimes.
I have a static method OAuthLogin::isThis() that returns a boolean whether the current login flow is OAuth or not (by checking session variables and URL parameters).
I don't like the name of the method but I can't think of a better one - I guess that is a common concept, therefore there should be some kind of pattern.
I don't like OAuthLogin::isThisOAuthLogin() because is redundant.
I would like to avoid Login::isThisOAuth because I would like to keep all the code in the OAuthLogin class.
Should I go for OAuthLogin::is()? Anything better than that?
Thanks.
Your OAuthLogin class should only have one responsibility, and that is to enable a user to login using OAuth; this class should have no knowledge of the "traditional" login process. A person who sees this class name (e.g. StackOverflow users!) will assume that this class is only responsible for login functionality using OAuth.
As your two login processes share a lot of code, then you really should refactor your code so that you have a base class with the common code, and then have separate classes for OAuth and Traditional login which will both inherit from the base class. When your code executes you should then instantiate the login class that is appropriate for that user's session.
Also as your OAuthLogin class is static then how will it be able to handle many users logging-in at the same time? Hence another good reason to refactor it so that it is not static.
If you absolutely cannot refactor, then without seeing your code, it sounds as if the OAuthLogin class is really a mediator i.e. it encapsulates how a set of classes interact (in this case your login classes). So instead of using the name "OAuthLogin" you could call it "LoginMediator". You could then have the properties:
LoginMediator.isOauthLogin
and
LoginMediator.isTraditionalLogin
to distinguish between the different types of login which the mediator is using for that particular session. Though instead of using the word "Traditional" replace this with the other authentication mechanism you actually use (e.g. HTTP Basic Authentication, HTTP Digest Authentication, HTTPS Client Authentication etc.)
Note how I have chosen intention-revealing names for these properties. If a stranger was to read your code (e.g. me!) they would struggle to understand the purpose of "is()" and "isThis()" from just the method signature.
However, in the long run I really do recommend that you refactor your code so that you have classes with discrete responsibilities, as you will find that naming methods will be far easier as a result.
I would add a method to the base class which just returns the type of the login.
Class (pseudo-code)
class Login
method class
return self.class # Returns the current class.
end
end
Usage would be (also pseudo-code):
if currentLogin.class == OAuthLogin
# ..
else
# ..
end
This would let you add more types later on, without having to add type-specific methods for each login type, leaving the control flow outside of your classes.
I suggest one of:
OAuthLogin::isCurrent()
OAuthLogin::isCurrentLogin()
OAuthLogin::isCurrentFlow()
OAuthLogin::isCurrentLoginFlow()
OAuthLogin::isActive()
OAuthLogin::isActiveLogin()
OAuthLogin::isActiveFlow()
OAuthLogin::isActiveLoginFlow()
How about OAuthLogin::isUsed()?
I suggest OAUthLogin::isLoggedIn().
I'm working on a new iPhone/iPod app that includes the need to do web services requests. I've found methods for doing these requests synchronously, or asynchronously by setting the controller as the delegate. What I'd really like to be able to do, though, is to create a single class that can handle all web requests for the whole application, and just create an instance of that class when I need to use it. That way, cookies and common pieces of code can be handled in one place, rather than all over the app.
So far the only thing I thought of that could accomplish what I'm trying to do is to create a new thread that handles the request synchronously within itself, then sends a message back to the calling controller once the request is complete. Is there a better way to accomplish what I'm trying to do?
Cookies are already a shared resource.
I would suggest reading the URL Loading System Overview to get an idea of how Apple set everything up. From what you describe, you want something very similar to how they have set up the system, maybe with a Singleton class for the connection. You can also look at ASIHTTPRequests which is a good wrapper around all of the connections stuff.
I would not suggest writing my own code here. Lots and lots of people have solved this problem for you.
So I've been reading about the pros and cons about using Singleton, and I have a scenario which I'm not sure if I should use one, and I thought consulting you guys.
I'm writing an Iphone app which once in a while have to communicate to the server (HTTP) information about the user logged in.
This web service is getting called from different parts of my application.
What I actually need are 2 type of classes:
Responsible for communication with the server - responsible for http setting,the url,header,parameters and etc.
2.classes for each type of web service api - for exmpale UpdateUserInfo Class or SendResults Class. This c
The 2nd class would use the 1st , and all through the app I would need many calles to the 2nd classes.
Should I use Singleton to any of theses ? What is the best way to design it ?
Thanks guys!
Edit:
Example for the 1st class(Let's call it DataDownloader) method would be :
(NSData *) downloadDataWithRequest:(NSURLRequest *)
{
ASIHTTPRequest *dlRequest = [[ASIHTTPRequest alloc] initWithURL:[request URL]];
[dlRequest setTimeOutSeconds:20];
if(retryNum < 1)
retryNum = 1;
[dlRequest setNumberOfTimesToRetryOnTimeout:retryNum];
// and more of the same
}
ASIHTTPRequest is something we're using as an HTTP wrapper.
Now I wouldn't want to call this sequence of function each time I want to send the server an HTTP request, So the option would be to put that inside a dedicated class and create a new instance, or using a singletion.
What I can do for example is Using something like that :
[[UpdateUserInfo sharedInstance] updateInfo:info]
Which can be implemented by setting up a NSURLRequest using the param info , and calling
[[DataDownloader sharedInstance] downloadDataWithRequest:InfoUrlRequest]
Now, assuming the http request are asynchronous , I still can spawn multiple at the same time.
I hope it's clearer now.
What do you think is the best way to design it ?
I wouldn't see the singleton pattern as being a useful solution to the problem you're trying to solve. It's really designed as a technique to control access to a single/finite resource, which isn't meaningfully the case from what I can tell.
For example, is there any reason why you wouldn't permit a user to carry out two network related activities at the same time?
Incidentally, out of interest have you looked at Cocoa classes such as NSURLConnection? I'm not sure you'd need a lower level class to manage the server communications as you're envisaging - this class might suffice. (Had to tell without knowing more about what you're trying to achieve.)
Also don't forget ASIHTTPRequest. It's a full featured network library
http://allseeing-i.com/ASIHTTPRequest/
I usually (and that's personal preference) have one singleton that controls the network management (a singleton and facade pattern in one) as to not having more than the 5 allowed connections. Could be possible for you as well. That would be a singleton for part of your task 1.
But as BobC has already pointed out, ASIHTTPRequest should do everything you need.
Don't reinvent the wheel!
I use the singleton pattern to control access to a web-based API that uses ASIHTTPRequest, and it works very well. ASI uses NSOperationQueues for asynchronous requests, so you don't need to worry about requests clobbering each other.
Because I don't know the order that requests are returned, I sometimes allow my public API methods to supply userInfo dictionaries so my callbacks have some context when they fire.
I would use the Service Locator pattern to obtain each of the services needed in your application. There are a couple different ways to create the service locator. I prefer configuration at initialization over configuration during runtime.
http://en.wikipedia.org/wiki/Service_locator_pattern
I'm dealing with some asynchronous communication situations (Event-driven XML parsing, NSURLConnection response processing, etc.). I'll try to briefly explain my problem:
In my current scenario, there is a service provider (that can talk to a xml parser or do some network communication) and a client that can ask the service provider to perform some of its tasks asynchronously. In this scenario, when the service provider finishes its processing, it must communicate back the results to the client.
I'm trying to find a kind of pattern or rule of thumb to implement this kind of things and I see 3 possible solutions:
1. Use the delegation pattern: the client is the service provider's delegate and it will receive the results upon task completion.
2. Use a target/action approach: The client asks the service provider to perform a task and pass a selector that will have to be invoked by the service provider once it has finished the task.
3. Use notifications.
(Update) After a while of trying solution #2 (target and actions), I came to the conclusion that, in my case, it is better to use the delegation approach (#1). Here are the pros and cons of each option, as I see them:
Delegation approach:
1 (+) The upside of option 1 is that we can check for compile-time errors because the client must implement the service provider's delegate protocol.
1 (-) This is also a downside because it causes the client to be tight-coupled with the service provider as it has to implement its delegate protocol.
1 (+) It allows the programmer to easily browse the code and find what method of the client, the service provider is invoking to pass its results.
1 (-) From the client point of view, it is not that easy to find what method will be invoked by the service provider once it has the results. It's still easy, just go to the delegate protocol methods and that's it, but the #2 approach is more direct.
1 (-) We have to write more code: Define the delegate protocol and implement it.
1 (-) Also, the delegation pattern should be used, indeed, to delegate behavior. This scenario wouldn't be an exact case of delegation, semantically speaking.
Action/Target Approach
2 (+) The upside of option 2 is that when the service provider method is being called, the #selector specifying the callback action must also be specified, so the programmer knows right there which method will be invoked back to process the results.
2 (-) In opposition to this, it's hard to find which method will be called back in the client while browsing the service provider code. The programmer must go to the service invocation and see which #selector is being passed along.
2 (+) It's a more dynamic solution, and causes less coupling between parts.
2 (-) Perhaps one of the most important things: It can cause run-time errors and side effects, as the client can pass a selector that does not exist to the service provider.
2 (-) Using the simple and standard approach (#performSelector:withArgument:withArgument:) the service provider can only pass up to 2 arguments.
Notifications:
I wouldn't choose notifications because I think they are supposed to be used when more than one object need to be updated. Also, in this situation, I'd like to tell directly the delegate/target object what to do after the results are built.
Conclusion: At this point, I would choose the delegation mechanism. This approach provides more safety and allows easily browsing the code to follow the consequences of sending the delegate the results of the service provider actions. The negative aspects about this solution are that: it is a more static solution, we need to write more code (Protocol related stuff) and, semantically speaking, we're not talking really about delegation because the service provider wouldn't be delegating anything.
Am I missing something? what do you recommend and why?
Thanks!
You did miss a third option – notifications.
You could have the client observe for a notification from the service provider indicating that it has new data available. When the client receives this notification it can consume the data from the service provider.
This allows for nice loose coupling; some of the decision is just down to whether you want a push/pull system though.
Very good question.
I dont think I am qualified, just yet (as I am a newbie), to comment on which design pattern is better than the other. But just wanted to mention that the downside you mentioned in point 2 (runtime exception) can be avoided by
if([delegate respondsToSelector:callback]){
//call to callback here
}
Hope that helps to weigh the options
Another downside for the Delegation approach:
A service provider can only have one delegate. If your service provider is a singleton, and you have multiple clients, this pattern does not work.
This caused me to go for the Action/Target approach. My service provider holds state and is shared among multiple clients.