Gitit integration: custom authentication
John MacFarlane
little different. Currently, if you're using custom authentication
and you try to edit a page when you're not logged in, you just get a
server error saying that you need to log in with custom authentication --
but no indication of HOW to do this.
Suggested change: require custom authentication to specify
not just a custom getLoggedInUser, but a custom loginUserForm.
You could then display a link to the login page, for example, or
use a redirect. (We could also then revert that nasty error
message in ifLoggedIn.)
Thoughts?
John
Thomas Hartman
data AuthenticationMethod
= ... | CustomAuth (GititServerPart (Maybe User))
-- Defined in gitit-0.6.1:Network.Gitit.Types
instead of Mayber User
Either e User
where e is some kind of error type. I first thought e should just be
string, but then I thought it might be better to leave this more
general.
other ideas?
Thomas Hartman
Darcs hosting: patch-tag.com
Build a webapp with haskell: happstack.com
Thomas Hartman
had different levels of access regarding wiki security.
I have:
-- Be careful changing this function -- order matters, because we use
>= elsewhere to determine
-- degree of publicity of a RepoAccess value... the higher the value,
the more public.
data RepoAccess = Private | PublicallyReadable
| PublicallyEditable | AnonymouslyEditable
deriving (Show,Read,Ord,Eq,Typeable,Data)
instance Version RepoAccess
where the idea is that PublicallyEditable means anybody can edit it
but they have to at least register a username, and anonymouslyEditable
means ip-address only edits are permitted.
Benja was helping me implement this scheme for patch tag. This got
back burnered when I got bogged down in the dirtyness of earlier
versions of gitit, but after all the improvements lately I'm trying
again :)
But of course, if this was integrated into gitit that would be even better.
thomas.
Anton van Straaten
Does "a custom loginUserForm" refer to a Haskell function, or a page
name, or something else? It could be useful to allow an arbitrary URL
to be specified, in case authentication is handled outside of Haskell.
Specifying a URL would still allow a login link to be presented when
needed. Whatever that URL does would have to be wired into
getLoggedInUser somehow, but that's up to the implementor of a custom
scheme.
Anton
Thomas Hartman
wget (or equivalent hardwired haskell function) a url, no?
MightyByte
(and other tabs) are not displayed when the user is not logged in.
(Although I realize that not everyone will want this solution.)
Anton van Straaten
> if you allow arbitrary haskell IO actions, one such action could be to
> wget (or equivalent hardwired haskell function) a url, no?
That's complicated, compared to issuing a redirect or writing the login
URL to the error page. It could also create authentication problems,
since gitit would effectively become a "man in the middle", and would
look like a possible source of an attack.
Reading the original message more closely, I think John answered my
question in advance when he mentioned that a custom loginUserForm could
generate a redirect. That could send the client's browser to an
external authentication page.
I was thinking that a redirect would be needed anyway, since returning
an OK (200) response in response to a failed edit attempt would be
wrong. Being able to specifying the URL for that redirect would a
natural place for a hook. But it may also be desirable to be able to
return e.g. a 401 code to trigger the browser authentication dialog, so
I can see the advantage to using a Haskell function.
Anton
John MacFarlane
Actually, I think a Haskell function gives more flexibility.
If you want to redirect to an arbitrary URL, the Haskell function
could be very simple:
myLoginUserForm = seeOther "/my/login/page" $ toResponse ()
But you could do other things as well in a Haskell function, if you
wanted to. (Set a cookie, for example, which your login function
can read and use to return you to where you started.)
John
John MacFarlane
> In my application, I just changed the gitit template so that the edit
> (and other tabs) are not displayed when the user is not logged in.
> (Although I realize that not everyone will want this solution.)
doesn't solve the problem I mentioned in my original post. Try
editing a page while you're not logged in, and see what happens.
(Of course, you won't have this problem if the enclosing app requires
login in order to access the wiki at all - which may be the case for
you.)
John
Anton van Straaten
> Actually, I think a Haskell function gives more flexibility.
Agreed. I was thinking aloud, slowly. I usually catch up eventually.
:)
John MacFarlane
>
> While we're on the topic of authentication, it would be great if gitit
> had different levels of access regarding wiki security.
>
> I have:
>
> -- Be careful changing this function -- order matters, because we use
> >= elsewhere to determine
> -- degree of publicity of a RepoAccess value... the higher the value,
> the more public.
>
> data RepoAccess = Private | PublicallyReadable
> | PublicallyEditable | AnonymouslyEditable
> deriving (Show,Read,Ord,Eq,Typeable,Data)
> instance Version RepoAccess
>
> where the idea is that PublicallyEditable means anybody can edit it
> but they have to at least register a username, and anonymouslyEditable
> means ip-address only edits are permitted.
>
> Benja was helping me implement this scheme for patch tag. This got
> back burnered when I got bogged down in the dirtyness of earlier
> versions of gitit, but after all the improvements lately I'm trying
> again :)
>
> But of course, if this was integrated into gitit that would be even better.
I'm not sure I see the need for this complexity.
If you want your whole wiki to be private (not readable accept by
those authorized), you can simply put it under a path protected by
HTTP authentication. (And then you can also use gitit's HTTP
authentication feature, so users don't have to login twice.)
Or, if it's part of another happstack app, the enclosing app can
restrict access.
So Private doesn't really seem to me to be needed.
That leaves PublicallyReadable, PublicallyEditable, and
AnonymouslyEditable.
I don't really see the need for AnonymouslyEditable. Sure, people
have to register a username to make edits. But they don't have
to give their real name or email address or anything like that.
So they can pick whatever name they like. It's already anonymous,
if you want it to be! Of course, if you have logging turned on,
you can recover their IP addresses if people started behaving
badly.
That leaves the distinction between PublicallyReadable and
PublicallyEditable. I assume that PublicallyEditable is the
current gitit default, and PublicallyReadable is more restricted.
Is the idea that you can't edit pages at all through the web
interface, only directly through git or darcs? Or is the idea
that only specially authorized users can get accounts and edit
pages?
If the latter, then this is already possible -- just put
'/_register' under HTTP authentication, so you have to know
a special password to sign up for an account. Or use gitit's
"access question" feature. Or, if you're using gitit as a library,
use custom authentication.
John
Gwern Branwen
Hash: SHA512
On Tue, Jul 7, 2009 at 8:42 PM, John MacFarlane wrote:
> I don't really see the need for AnonymouslyEditable. Sure, people
> have to register a username to make edits. But they don't have
> to give their real name or email address or anything like that.
> So they can pick whatever name they like. It's already anonymous,
> if you want it to be! Of course, if you have logging turned on,
> you can recover their IP addresses if people started behaving
> badly.
This is true, but it is still another barrier to participation.
'Beware the Turing Tarpit, where everything is possible but nothing of
interest is easy.' As the English Wikipedia has demonstrated, the
difference in casual contribution levels between registration-required
and registration-optional can be substantial.
- --
gwern
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEAREKAAYFAkpT9fsACgkQvpDo5Pfl1oLNLACfaTA6zXV8oMxC+eh3FMjwC3Ri
A2UAoIkztmkM0/rzAbUylBDZpNisIr/b
=EW27
-----END PGP SIGNATURE-----
Claes
On Jul 8, 2:42 am, John MacFarlane <fiddlosop...@gmail.com> wrote:
>
> If you want your whole wiki to be private (not readable accept by
> those authorized), you can simply put it under a path protected by
> HTTP authentication.
Since it is not clear to me from the documentation, my best guess is
that HTTP authentication takes place by Apache in an Apache-gitit
setup?
Thanks,
Claes
John MacFarlane
>
>
> On Jul 8, 2:42 am, John MacFarlane <fiddlosop...@gmail.com> wrote:
> >
> > If you want your whole wiki to be private (not readable accept by
> > those authorized), you can simply put it under a path protected by
> > HTTP authentication.
>
> Hi, a question from a novice user: is this possible with just gitit?
authentication.
John