bennomadic / django-webid-provider Goto Github PK

we should pass objects_all manager to admin
(now admin is taking the default "objects" manager, which does not display keys in revoked certificates)

I think, from user perspective, it's more natural to identify her certificates by a given name or comment, rather than hashes.

Currently, we are using something real dirty: a text-field in the singleton "default certificate values" model. That's dangerous! (i.e, any admin can break havoc by changing it).

To be generic, we should give site admin the freedom to choose any field (and uri pattern).
Using GFK?

caveat: if this is allowed to change, we have to change also the way we're accessing the
webid_url and absolute_webid_uri. I.e, once the certificate has been created, we should always refer to the same URI. I think we should store it as a textfield in the webiduser model (and property acess that, and dynamically building the uri as a fallback).

related to that "profile" integration ticket.
make things smooth :)

Having only the username in the cert makes it confusing for the user:
when she has to pick from the cert selection UI there's nothing that helps to choose the
proper cert for a given site.

We could:
a) introduce site url in the cert CN --> ben [webid.rhizolab.org]
b) change Issuer name ("not a certification authority")
c) let user choose the name that will be displayed (in advanced view, perhaps?)

look into d2rq integration.
only the AUTH_PROFILE_APP setting should be needed.

it's better if we move the webid-related fields to WebIDUser model.
We're going to use it in django-webid-auth project (basic proxy model for auth'n.)

first, we neeed a basic WebID client, that can be a reusable python project.

check internet connectivity if it's going to be used on the django testsuite.

current chrome keygen implementation lacks of any user feedback.

1. file a bug in chromium tracker.
2. meanwhile, do something with javascript (some popup telling user to wait?...)

It seems that some bits should be adapted for compatibility with django 1.5...

Thanks in advance.

we need to think about possible use cases of the app,
and write decorators for view according to defaults

1. who can make a WebID?
2. integration with django-registration?
3. create user views? only in demo site, or wired with the app?
   (ideally, installing django-webid bundle package is the only thing needed to have
   webid functionallity up and running).
4. django-webid-auth integration: we only allow webid login
   (so first we create a user, w/o password)

I need to review the reusable django apps docs, and split core functionalities from demo-site ones.

just thought about this (not very important, but worth considering before users start getting certs in da wild)...

the current sample urlpatterns deliver simple, minimal, nice-looking webid uris:

example.net/webid/name#me

we have (in the sample server) set the package namespace that way (/webid/)
so all hangs from there:

/webid/certs
/webid/cert/add
/webid/cert/xx

if that's going to be the default urlpattern logic, we have to ensure somehow that names (or potentially any other identifier) does not clash with api.

solutions:

1. resolve username-based webid uris after all api patters (to avoid DOSing api, hehe)

2. move ids to other url-space in the sample settings: example.org/people/foo#me
   (and, in docs, boldly advice users to do so... and warn somehow if url mangling is detected)

3. keep it all under /webid/ namespace, but avoid certain usernames (api, for instance):
   /webid/api/cert/...
   /webid/user#me

   problem: how to interact with user registration???
   now we have our simple registration form for demoing purposes, but I want to get rid of that asap.

4. delegating profile responsability to 3rd-party apps, and forgetting about the issue. uh-oh. (See issue #66 about profile integration)

By now, I like option 2. KISS.

I've tried to follow here 2 different strategies: delivering the x-x509-user-cert in a iframe, and using the mime multipart/x-mixed-replace comet tecnnique.

Sadly, only FF and Opera seem to honor these techniques. Not sure about the undelying reasons, but could try to track cause and file bugs in the chromium tracker.

Hmm... I'm thinking now about another trick that we could use as a workaround:
have a javascript timer / redirect.

the certificate that the app is generating does not include the valid uses.

little link that shows the advanced form.
(ajax-y?)

To be added:

• Show key bits selector if it was hidden.
• Custom expiration overrides: days, even hours.
  (very useful for temporary cert installation. make user aware of that possibility:
  i.e., you are in a public computer: create a temp cert, use it, and revoke it.
  other possibility: mark a cert as one-shot, and have it automatically revoked after session
  expiration :)
• Custom common name?

• Could include a layman's WebID explanation + screencasts, etc.
• Should be upgraded as the UI evolves.
• With screenshots on main browsers.

@dominique: what do you think about the right timing to do this? I think we should wait until we have a more stable/integrated UI.

I thought it could be good to have a separate package for this (with optional switches from -provider, so it gets included in the templaetes if present and enabled). It could improve maintanability.

the idea is making it ultra-easy for the layman.
(key bits? uh?)

now we have in place a little javascript hack, which is enabled from the admin interface:
http://webid.rhizolab.org/admin/provider/certconfig/1/
"hide keygen form".

ideally, the form is there but we only display:hide it, letting the user with only a "give me a cert" big button.

some work still needed at css level.

the "advanced" view can restore the form, with some extra options.

included in Cert admin.

assume that the view in charge could live in an external app.
have some sensible default and a settings key.

after the xmppwebid revamp, currently we're only using it for pkcs12 certs.
do we want them on the release? they're a good fallback for some clients, but not
a high prio methinks (and currently p12 views are half-broken)

one option could be refactoring all the openssl calls to use m2crypto.
but for now we can stop using the p12 functionality and remove that dep

we will need it for things like:

1. deliver user tailored help (screenshots, etc)
2. return workarounds about known browser implementations (some outstanding bugs)

and have it in readthedocs :)

Have to think about best design.

check that the whole process goes smooth.
(basic cert enrolling process is working, afaik. We have to check IE support for cert delivering:
iframes / multipart??)

with proper alternates.

We should stay in alpha for a time (to see if we need to change the db schemes, basically, adding or refactoring models.)

After this ticket is marked as "resolved", we should assume that we have users, and we will begin using south for database migrations (now is cheaper just to destroy and recreate db).

it can be useful to know when a given certificate has been revoked
(we have to decide if the revocation is permanent, or can be undone)

right now it's only a ul.

for displaying the looong mods.
Try some js?
I think it's better to have it turned into a template filter.

If we're going to serve webids over https, it has to be setted from the beginning
(webid certs will have this URI).
needing a settings key.

in case the user wants to know / undo revocation