HangFire Monitor authorization about hangfire HOT 20 CLOSED

As a workaround, if you are using role-based authorization in your application, you could use the following method of HTTP handler plug-in (but remove the registration of hangfire.axd handler in other places of web.config):

<location path="hangfire.axd" inheritInChildApplications="false">
  <system.web>
    <authorization>
      <allow roles="Administrator" />
      <deny users="*" />
    </authorization>
  </system.web>
  <system.webServer>
    <handlers>
      <add name="HangFire" path="hangfire.axd" verb="*" type="HangFire.Web.HangFirePageFactory, HangFire.Web" />
    </handlers>
  </system.webServer>
</location>

from hangfire.

this is great, i was going to ask to disable it by default.

thank you

from hangfire.

@odinserj have you pushed a new release with this fix?

from hangfire.

Not yet

from hangfire.

Is there a way to programatically configure who sees the web ui?

from hangfire.

Only via web.config. Do you have ASP.NET RoleProvider integrated in your app to use the given workaround?

from hangfire.

no, I do not use the built in role provider.

from hangfire.

Is there any way some sort of filter could be applied? That way I can get the current user, check against the database if the user is admin or not...?

from hangfire.

right now, the web.config works with Owin Roles Claim as i confirmed here in #59

but it would really be much better, if we can integrate HangFire directly with Owin, as it is the Defacto now for Membership.

also i think maybe if we can some how add hangfire monitoring URL to ASP.NET Routing, it would be great, where we can specify authorization Attribute.

the reason for all above, is when you ahve large Membership system with many Admins, you need to set up specific permissions for them like, read only, write, etc... and Hangfire in my humble opinion really needs that, cause for example i only want Super Admins to have the ability to cancel jobs, and Admins group to see only Job queue.

from hangfire.

I only really have admin and non admin - i.e. everyone else that is using my system. So I dont really have a too complex membership system.

from hangfire.

@hahmed i do have :)
here is an idea that might help with Hangfire
http://beletsky.net/2011/03/integrating-elmah-to-aspnet-mvc-in.html
http://stackoverflow.com/questions/7005389/how-to-provide-only-access-for-elmah-axd-for-administrator-login-in-web

from hangfire.

You are telling me about two use cases:

1. I should be able to specify simple authorization rules, but I don't have any role provider installed, because it complicates my application (and I understand it).
2. I should be able to use complex authorization system, that have different authorization policies based on different use cases (page view, job retry, job cancellation and so on).

This two cases may be solved with flexible authorization system, like in Glimpse. It is really needed, but I have no plans to implement it yet (I'm making HangFire.Core more stable now). But if you need it now, or want to implement more simple authorization rules for the first case only, you can describe what you want to do in a separate issue, and send a pull request.

from hangfire.

@devmondo, I don't want to introduce such thing (elmah controller) in a HangFire.Web library, because it looks like a crutch and breaks encapsulation. I have plans to implement HangFire.Web using OWIN, and Glimpse-like authorization policies looks much better.

But links are nice, especially if you can not do anything else 😄

from hangfire.

Heh, current rules are simple enough:

if (!HangFireConfiguration.EnableRemoteMonitorAccess && !context.Request.IsLocal)
{
    return HttpStatusHandler.Process(context, HttpStatusCode.Unauthorized);
}

Feel free to modify them!

from hangfire.

@odinserj thanks for the input,
Glimpse looks ok, and i understand your point about complex permissions, that is why i suggested Owin, where in the future when you decide to implement such a thing, cause with Claims authorization things are really much easier and precise to handle the above.

we are fine with the current security implementation, and i am in no position to just ask and get served, you are the man who is gracing us with his time for free, do what you think is best for all of us, what i am trying to do here is suggesting Ideas to make Hangfire greater :)
HangFire really made my life better, i was using NserviceBus and seriously most of the time and i dare to say 90% of the time hangFire does what Nservice Bus do, without all those whistles.

the best Part is that more features are getting implemented like Cancellation Token, Tutorials, Stabilizing the Core, etc...

P.S it is true i can't do what you can do but i did a shameless useless Simple Injector Integration :)

i wish i can help more, but your knowledge is beyond me :)

hangfire rules :)

from hangfire.

hey i love that Rules part, never knew them, you can add them to Docs, this will shed some good light, really :)

P.S, from your experience is "context.Request.IsLocal" really secure and really works only if request is local ?

from hangfire.

@devmondo, thanks for good words. To make it more clear, I like feature requests. More feature requests -> better understanding what do you need -> more thoughts what other users need -> more thoughts about direction and prioritization -> better project. So, I very appreciate them.

P.S. HangFire.SimpleInjector beats HangFire.Ninject and HangFire.Autofac as for now, so you can't call it "shameless and useless" :)
P.P.S.

internal bool IsLocal()
{
    string remoteAddress = this.GetRemoteAddress();
    return !string.IsNullOrEmpty(remoteAddress) && (remoteAddress == "127.0.0.1" || remoteAddress == "::1" || remoteAddress == this.GetLocalAddress());
}

P.P.P.S. These simple authorization rules will be in 0.8.

from hangfire.

Feel free to modify them!

Where would you modify them?

Do I create my own build and use that in my application?

from hangfire.

If you are planning to create a solution (it may be simple) that will help other users with the same problem, please, create another issue with problem and proposing solution, and make a pull request. But there are breaking changes in current branch, and I will not be able to push the solution before 0.8 release.

from hangfire.

@hahmed , you can modify them in Global.asax, in static class, even while application running, I Think hangFire is Static and last through the application life time until recycle, unless i am wrong.

@odinserj thank you very much for your kind words, you encouraged me, i was under the impression that you don't want much of those extra ideas, but now i get you, you are trying to balance things up, what is first and what should be done later, based on users requests, this is great of you. you sound like the perfectiones methodical kind of guy, i love that and i look up to be one as this is my personality but my coding skills are still normal, but i am learning.

i really think HangFire will solve all background jobs problems and we should not use other libraries, and in my humble opinion you must make it like and that this should be the plan, and more people should know about it.

i don't see why i should use FluentScheduler, or Quartz, when a lot of their features intersect with HangFire, but with Hangfire there more simplicity,control and stability not to mention that Hangfire surrvies Application restarts which is a BIG PLUS, again, my dream is to see HangFire completely eliminate the need for anything else, ok maybe not large enterprise stuff, but who cares, how often you have one of those really really big projects, and i would help to make this happen where and when ever i can, you have got a solid foundation here, that by time and Input will be the best out there.

regarding Owin the best part is that it is agnostic, so you can use it in Web, Desktop App, Service, etc... and that fits nicely with HangFireCore.

may i suggest you add a RoadMap and Change Log to the Git Hub page, this will help a lot.

P.S.S.S could you explain to me how SimpleInjector Integration beats other IOC ones :)

from hangfire.