I'm trying to figure out how to get my web application to handle AuthAlreadyAssociated Exception and tell the user they can't do that. (see AuthAlreadyAssociated Exception in Django Social Auth) Is there a way to invoke my subclass without forking DSA?
Oh, https://docs.djangoproject.com/en/dev/topics/http/middleware/ Hmmm.
But the provided app doesn't work as django middleware class. Need to look at example.
Related
We have gone into production with a GWT/RequestFactory based app. All pretty good but debugging is tough as we currently don't always know the service methods being called.
What is best practice for making life easy for ourselves when we have problems in our logs?
We use MDC to have username, user agent in our logs but it doesn't look that easy to log RequestFactory service method.
Many thanks
You can use a ServiceLayerDecorator and override its invoke method to add your log (or MDC key/value) here.
Im trying to set up a system similar to this web site
http://www.appmakr.com/
My problem is the uploading to the appstore. does anyone has an idea about how to make this process automatic? the only way i can think of is mimicking the web requests and the application loader but is there an interface for that ?
Thanks in advance.
All web request boil down to simple PUT/POST/GET/DELETE etc… calls. Mimicking a user through code is possible and the only way to do this as there is no API. Get an app like HTTPScoop to determine how to form the requests yourself, then use curl or some other net tool to emulate the requests in code, with the appropriate delay.
I see a lot of articles and posts on how to create a custom MembershipProvider, but haven't found any explanation as to why I must/should use it in my MVC2 web app. Apart from "Hey, security is hard!", what are critical parts of the whole MembershipProvider subsystem that I should know about that I don't, because I've only read about how to override parts of it? Is there some "behind the scenes magic" that I don't see and will have to implement myself? Is there some attribute or other piece of functionality that will trip over itself without a properly setup MembershipProvider?
I am building a web app, using a DDD approach, so the way I see it, I have a User entity and a Group entity. I don't need to customize ValidateUser() under the provider; I can just have it as a method on my User entity. I have to have a User object anyways, to implement things not under the MemebrshipProvider?
So, what gives? :)
No, you don't need it. I have sites that use it and sites that don't. One reason to use it is that plumbing is already there for it in ASP.NET and you can easily implement authentication by simply providing the proper configuration items (and setting up the DB or AD or whatever).
A RoleProvider, on the other hand, comes in very handy when using the built-in AuthorizeAttributes and derivatives. Implementing a RoleProvider will save you a fair amount of custom programming on the authorization side.
On an asp.net mvc 2 app, I'm using Unity 2.0 interception app for various types of logging where every log entry requires the id of the current user.
Currently I'm passing the User object as an argument to service and repository methods. The only reason I'm doing this is so that it's available on MethodInvocation.Argumants for the intercepted method. Ideally, I'd like to supply the interceptor with a User object somehow. This doesn't seem to be possible. Does anybody know if it is or if any other .net AOP tool provides this? I also remember this being a problem several years ago on a project using Spring/Java so I guess it is a common problem that hopefully someone has solved?
I worked it out.
To handle the intercepted calls, you have to supply an implementation of ICallHandler.
Add a User parameter to the implementation's constructor.
I'm developing an app that will talk with a web service exposing multiple methods. I'm trying to figure out what the best pattern would be to centralize the access to the web service, give options for synchronous and asynchronous access, and return data to clients. Has anybody tackled this problem yet?
One class for all methods seems like it would centralize everything well, but I'm thinking it would get confusing to return data to the correct places, especially when dealing with multiple asynchronous calls. Another thought I had was a separate subclass for each method, with some sort of factory brokering access, but I'm thinking that might be overengineering the situation.
(note: not asking for what method calls to use/how to parse response/etc, looking for a high level design pattern solution to the general problem)
I recently came across the same problem. While I don't believe my solution to be optimal, it may help you out.
I created a web service manager and an endpoint protocol. Each object that implements the endpoint protocol is responsible for connecting to a web service endpoint(method), parsing the returned data, and notifying its delegate(usually the web service manager) of completion or any errors. I ended up creating an EndpointBase class that I use 99% of the time.
The web service manager is responsible for instantiating the endpoints as needed and invoking them. All of the calls happen asynchronously.
All in all it seems to work pretty well for me. I did end up with a situation in which one endpoint relied on the response of another (I used the command pattern there).
SDK Components that you'll want to look at are:
NSURLConnection
NSXMLParser
Factories? We don't need no stinkin' factories.
I've done this a few times, and I basically do what you're saying: one object that provides methods for all the web service calls, encapsulating the details of communicating with the service, handling connection issues, etc. In one app it was a singleton, because it needed to keep session state; in another app it was just a collection of static methods.
Along with some formatting of the response data, that's the entirety of its responsibility.
It's left up to the callers is whether the call is synchronous or asynchronous; the class itself is written synchronously, and a caller just uses it in a separate thread if necessary. Cocoa's performSelector... methods make that easy.
If REST is a good fit for your data interactions, then I would suggest the ObjectiveResource library . It's designed to work seamlessly with a Ruby on Rails app, but it basically speaks JSON or POX (plain old XML) over HTTP using rails ActiveResource conventions.
It's basically a set of categories on NSObject and some of the primitive object types that will let you make calls like [Dog findAllRemote] to return a list of Dog objects, or [myDog saveRemote] to send changes made to the myDog object back to the server.