djangoldp-account issueshttps://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues2022-10-21T13:03:32+02:00https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/81Changing username without changing web-id2022-10-21T13:03:32+02:00Calum MackervoyChanging username without changing web-idA few times in the past people have asked about changing their username for their account - we're using username automatically in the WebID of the user and normally we respond with an explanation that [Cool URIs don't change](https://www...A few times in the past people have asked about changing their username for their account - we're using username automatically in the WebID of the user and normally we respond with an explanation that [Cool URIs don't change](https://www.w3.org/Provider/Style/URI)
It occurred to me that we could update the username without updating the WebID. I don't know if there's a reason why we can't do this, possibly a UX reason that users might find it weird if `WebID != username`?https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/80CORS errors2022-06-01T18:18:01+02:00Calum MackervoyCORS errorsWhen visiting https://community.startinblox.com/ using Firefox, I have a bunch of failed requests to `/users/` on various servers, with the error message. I'm still able to use the app as far as I can tell, so it's not critical
> Cross-...When visiting https://community.startinblox.com/ using Firefox, I have a bunch of failed requests to `/users/` on various servers, with the error message. I'm still able to use the app as far as I can tell, so it's not critical
> Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.paca.happy-dev.fr/users/. (Reason: CORS request did not succeed). Status code: (null)
In the past a CORS error has been returned when there was another problem (https://git.startinblox.com/djangoldp-packages/djangoldp/-/issues/358)
@balessan do you have this behaviour?https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/79default_redirect_uri can become invalid2021-11-05T15:17:46+01:00Calum Mackervoydefault_redirect_uri can become invalidMyself and @plup fixed a bug just now with a user who had a `default_redirect_uri` which was taking them back to the OIDC `authorize` view with an old (now invalid) `client_id`. So they successfully login, and they're taken back to an in...Myself and @plup fixed a bug just now with a user who had a `default_redirect_uri` which was taking them back to the OIDC `authorize` view with an old (now invalid) `client_id`. So they successfully login, and they're taken back to an invalid screen
There was a similar issue where an error string was included in the redirect URI and this led people
The `default_redirect_uri` was included on the user model as a mechanism to know where to redirect someone when none was passed in with the request (especially on federated login - the idea was that I visit one client application, I'm redirected to my identity provider, but the client didn't pass in that request where to redirect them back, so it looks at the last lodged in app stored as `default_redirect_uri`. Clearly if this has been set to an error URI then it will look like I've hit an error!)https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/78Change default anonymous permissions to none2021-08-20T14:24:08+02:00Calum MackervoyChange default anonymous permissions to noneThe code to change this was simple, just needs to reopen the MR here: https://git.startinblox.com/djangoldp-packages/djangoldp-account/merge_requests/94
However making this change would make the user model incompatible with DjangoLDP-no...The code to change this was simple, just needs to reopen the MR here: https://git.startinblox.com/djangoldp-packages/djangoldp-account/merge_requests/94
However making this change would make the user model incompatible with DjangoLDP-notification which does not authenticate its requests:https://git.startinblox.com/djangoldp-packages/djangoldp-notification/issues/42
Blocked waiting on solutions. It's a variation of the same issue in DjangoLDP core, so we've already investigated.
Solutions could be to authenticate it with the server key or with a user agent:
* https://git.startinblox.com/djangoldp-packages/djangoldp/issues/236
* https://git.startinblox.com/djangoldp-packages/djangoldp/issues/372
Once this is resolved, there is some extra work needed to support field-level permissions on the user. See the thread here: https://git.startinblox.com/djangoldp-packages/djangoldp-account/merge_requests/94#note_66440https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/76Case-insensitive username & WebID2021-04-09T16:46:40+02:00Calum MackervoyCase-insensitive username & WebIDAs part of #74 we'd been discussing the username case sensitivity too
Since we're using the username in the WebID, the WebID being a URI means that `http://server/users/tom/`, `http://server/users/tOm/` and `http://server/USERS/tom/` ar...As part of #74 we'd been discussing the username case sensitivity too
Since we're using the username in the WebID, the WebID being a URI means that `http://server/users/tom/`, `http://server/users/tOm/` and `http://server/USERS/tom/` are all distinct users
It would suggest that we can't make the username insensitive, but @jbpasquier made the suggestion that we could make it insensitive if we made `.../tOm/` redirect to `tom`
A priori this could be done by overriding the viewset being used on the `LDPUser` model (on the `/users/` path)Sylvain LlopSylvain Llophttps://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/75User model best practices2021-04-08T01:42:07+02:00Calum MackervoyUser model best practicesPing @balessan
A similar issue to #74 came up with username and @jbpasquier asked if we're following a standard for usernames
I read this: https://django-improved-user.readthedocs.io/en/latest/rationale.html and it occurred to me that...Ping @balessan
A similar issue to #74 came up with username and @jbpasquier asked if we're following a standard for usernames
I read this: https://django-improved-user.readthedocs.io/en/latest/rationale.html and it occurred to me that Django chooses to ignore these problems and make them an application implementation detail
I think it's likely that we would prefer the maintenance work associated with improving the `LDPUser` (possibly adding `django-improved-user` as a dependency ?)
* a number of packages are tightly coupled to `LDPUser`
* we plan to provide `LDPUser` as support for a Solid POD (#72 )https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/74Unique is case sensitive but email domain isn't2022-09-19T19:05:27+02:00Calum MackervoyUnique is case sensitive but email domain isn'tEmail domains are not case sensitive but the unique constraint in Django is, so `EmailField(unique=True)` allows for duplicate emails to be registered in the database
### "Email domains are not case sensitive"
https://django-improved-u...Email domains are not case sensitive but the unique constraint in Django is, so `EmailField(unique=True)` allows for duplicate emails to be registered in the database
### "Email domains are not case sensitive"
https://django-improved-user.readthedocs.io/en/latest/email_warning.html
[RFC 5321](https://tools.ietf.org/rfc/rfc5321.txt) states that the mailbox in mailbox@hostname of an email format is case-sensitive. `ANDREW@example.com` and `andrew@example.com` are therefore different email addresses (the domain is case-insensitive).https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/73Logging into a DjangoLDP/LDPUser application with a Solid Pod2022-07-09T13:03:11+02:00Calum MackervoyLogging into a DjangoLDP/LDPUser application with a Solid PodNeeds testing, but behaving well I should be able to login to a Startin'Blox app using a Solid Pod
Django's schema requiring an "authentication model" means that an `LDPUser` will necessarily be created by our authentication backend if ...Needs testing, but behaving well I should be able to login to a Startin'Blox app using a Solid Pod
Django's schema requiring an "authentication model" means that an `LDPUser` will necessarily be created by our authentication backend if the login is successful but this isn't failure behaviour - the `LDPUser` will be a backlinked only relevant for its `urlid`, which should be pointing to my Solid profile resourcehttps://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/72DjangoLDP-Account: Database-backed Solid-POD provider?2021-03-24T09:47:52+01:00Calum MackervoyDjangoLDP-Account: Database-backed Solid-POD provider?At the moment this package provides authentication for the Resource Server side of Solid-OIDC (#70 ) (i.e. for the server application to which the client is connecting), and it provides a federated user model (`LDPUser`) which is decisiv...At the moment this package provides authentication for the Resource Server side of Solid-OIDC (#70 ) (i.e. for the server application to which the client is connecting), and it provides a federated user model (`LDPUser`) which is decisively _not_ a Solid Pod
I assume that this isn't a short-term objective but worth investigating the possibility of providing a Solid Pod with DjangoLDP-Account or a new package, and what changes would need to be made to DjangoLDP
If we did go down this track, I think it'd be very challenging to efficiently model the kind of "infinite variety of fields" (the Open World Assumption) which a triplestore offers, but incredibly useful for standards compliance in DjangoLDP in general if we did provide this. I did a little investigating into Apache Jena's SQL-backed SDB, but they've discontinued this effort. It would be interesting to find out what they were doing and why they discontinued it
They provide a Triplestore-backed database system which is largely discussed as being fast, but I haven't seen any benchmark comparisons. Being able to separate the datasets into separate files is quite nice. Extending Django with a new Triplestore Database provider is possible, and it wouldn't necessarily mean that users can't use SQL-backed databases as well or instead
If we were successful in this effort it would provide a serious performance improvement over conventional filesystem-backed Pods (https://forum.solidproject.org/t/constructive-criticism-from-an-experienced-developer/3521)https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/71Unmaintained dependency: JWKest2021-02-23T18:30:40+01:00Calum MackervoyUnmaintained dependency: JWKest`djangoldp_account` replica of https://git.startinblox.com/djangoldp-packages/django-webidoidc-provider/issues/3`djangoldp_account` replica of https://git.startinblox.com/djangoldp-packages/django-webidoidc-provider/issues/3https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/66User receives 2 emails after registration - can we merge into one?2021-01-22T11:17:43+01:00LouisUser receives 2 emails after registration - can we merge into one?Issue found on https://community.spacecoop.eu/
When registering, the user receives 2 emails:
* account creation ![Capture_d_écran_2021-01-20_145616](/uploads/b0db51e56bd4ad058090629d7fe213f8/Capture_d_écran_2021-01-20_145616.png)
* ac...Issue found on https://community.spacecoop.eu/
When registering, the user receives 2 emails:
* account creation ![Capture_d_écran_2021-01-20_145616](/uploads/b0db51e56bd4ad058090629d7fe213f8/Capture_d_écran_2021-01-20_145616.png)
* account registration ![Capture_d_écran_2021-01-20_145833](/uploads/5e7458e39a7400c0fdf65b54d15bb264/Capture_d_écran_2021-01-20_145833.png)
Those 2 emails may be confusing for the user. Is there a point in keeping them separate?
Already notified previously here: https://git.startinblox.com/applications/space-coop/plateforme-hubl/issues/1https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/64Error setting up DjangoLDPv2 locally with DjangoLDP-Account2022-02-15T12:28:14+01:00Calum MackervoyError setting up DjangoLDPv2 locally with DjangoLDP-Account@plup wondering if you're able to help me with this.. I'm finding that I'm not able to login after setting up a local server
steps to reproduce
1. set up a new virtual environment
2. set up a new server with the `settings.yml` below
3. ...@plup wondering if you're able to help me with this.. I'm finding that I'm not able to login after setting up a local server
steps to reproduce
1. set up a new virtual environment
2. set up a new server with the `settings.yml` below
3. run `python manage.py createsuperuser`
4. run `djangoldp runserver`
5. try to login at `127.0.0.1:8000`. For me no error is thrown but I'm not logged in
settings.yml
```
dependencies:
- djangoldp-account
ldppackages:
- djangoldp_account
server:
# DjangoLDP required settings
DEBUG: true
ALLOWED_HOSTS:
- '*'
SECRET_KEY: 'cdf%vfqi$s*)r7i22=y-&5#^^p6(cwefq^1m)l&b7#n6kg@6#)'
DATABASES:
default:
ENGINE: django.db.backends.sqlite3
NAME: db.sqlite3
LDP_RDF_CONTEXT: https://cdn.happy-dev.fr/owl/hdcontext.jsonld
ROOT_URLCONF: server.urls
STATIC_ROOT: static
MEDIA_ROOT: media
```https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/61Cookies should not be used to identify users when bearer token is provided2021-05-18T15:15:09+02:00Fabien QuatravauxCookies should not be used to identify users when bearer token is providedToday, If I authenticate on DjangoLDP instance A in client A, I get two auth means : a cookie `sessionid` and a JWT bearer token stored in browser localStorage. If I then authenticate to another DjangoLDP instance B in client B and that ...Today, If I authenticate on DjangoLDP instance A in client A, I get two auth means : a cookie `sessionid` and a JWT bearer token stored in browser localStorage. If I then authenticate to another DjangoLDP instance B in client B and that instance B is federated with instance A, I start to be in trouble : client B sends bearer token B and cookie A to server A, and server A authenticates me as user A instead of user B.
I think that the session cookie should only be used to first generate the access token, but not in subsequent requests.https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/60[i18n] Provide pot file along with po and mo2020-11-13T10:07:56+01:00Fabien Quatravaux[i18n] Provide pot file along with po and moIn order to ease new language additions and already existing languages, a `pot` file should be provided along with `po` and `mo` file. The `pot` file is basically a `po` template that contains only the strings to translates, with no tran...In order to ease new language additions and already existing languages, a `pot` file should be provided along with `po` and `mo` file. The `pot` file is basically a `po` template that contains only the strings to translates, with no translations. It can be generated automatically ([see here for example](https://www.mattlayman.com/blog/2015/i18n/#extracting-the-master-list)) and used by tools like [POEdit](https://poedit.net/) to create or update po/mo files.https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/53Unability to update the Account Picture in Nested Field2022-07-09T13:04:34+02:00Benoit Alessandronibenoit@startinblox.comUnability to update the Account Picture in Nested FieldI tried different ways from the client-side to update the account picture and it seems it is never saved.
An example of sib-form is as follow:
```
sib-form#entrepreneur_profile_picture.block_log.block_creat_count(
bind-user
nest...I tried different ways from the client-side to update the account picture and it seems it is never saved.
An example of sib-form is as follow:
```
sib-form#entrepreneur_profile_picture.block_log.block_creat_count(
bind-user
nested-field="account"
fields="foaf:depiction, slug, issuer"
widget-issuer="sib-form-hidden"
widget-slug="sib-form-hidden"
upload-url-foaf:depiction=`${sdn}upload/`
widget-foaf:depiction='cs-ent-profile-picture'
class-foaf:depiction='input_photo w_25'
submit-button=`${data.SaveModification}`
)
```
An example of CURL request that generates is as follows:
```
curl 'http://localhost:8000/accounts/balessan_en/' -X PUT -H 'User-Agent: ...' -H 'Accept: */*' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Referer: http://localhost:9000/en/entrepreneur-dashboard/entrepreneur-account-edit' -H 'authorization: ...' -H 'content-type: application/ld+json' -H 'Origin: http://localhost:9000' -H 'Connection: keep-alive' -H 'Cookie: ...' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' --data-raw '{"foaf:depiction":"http://localhost:8000/media/Capture%20d%E2%80%99%C3%A9cran%20de%202020-04-20%2019-02-21_TDmxTTZ.png","slug":"balessan_en","issuer":"","@id":"http://localhost:8000/accounts/balessan_en/","@context":{"@vocab":"http://happy-dev.fr/owl/#","rdf":"http://www.w3.org/1999/02/22-rdf-syntax-ns#","rdfs":"http://www.w3.org/2000/01/rdf-schema#","ldp":"http://www.w3.org/ns/ldp#","foaf":"http://xmlns.com/foaf/0.1/","name":"rdfs:label","acl":"http://www.w3.org/ns/auth/acl#","permissions":"acl:accessControl","mode":"acl:mode","geo":"http://www.w3.org/2003/01/geo/wgs84_pos#","lat":"geo:lat","lng":"geo:long","entrepreneurProfile":"http://happy-dev.fr/owl/#entrepreneur_profile","mentorProfile":"http://happy-dev.fr/owl/#mentor_profile","account":"hd:account","messageSet":"http://happy-dev.fr/owl/#message_set","author":"http://happy-dev.fr/owl/#author_user","title":"http://happy-dev.fr/owl/#title","picture":"foaf:depiction"}}'
```
I am pretty sure that used to work, looks like a regression to me.
Both using `picture` or `foaf:depiction` as predicate changes nothing.
Changing the field value through the admin works.
I'd like to help on debugging that but do not know where to start to be efficient.
Any idea ?https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/49I would like to control which OIDC providers users can login to my server thr...2021-07-13T16:50:25+02:00Calum MackervoyI would like to control which OIDC providers users can login to my server throughI propose that we do this through optional `PROVIDERS_WHITELIST` and `PROVIDERS_BLACKLIST` settings
Possibly we could use `LDPSource` or similar so that it's configured through the admin panel
Have we discussed other means for controll...I propose that we do this through optional `PROVIDERS_WHITELIST` and `PROVIDERS_BLACKLIST` settings
Possibly we could use `LDPSource` or similar so that it's configured through the admin panel
Have we discussed other means for controlling with whom I federate? Has this issue been discussed within the Solid community?
@sylvain @balessan @jbpasquier
@plup I can't think of any security issues with being able to use any server as an OIDC provider, as long as it's intentional that anyone could gain "authenticated users" permissionshttps://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/48User-friendly federated login2020-04-16T18:44:38+02:00Calum MackervoyUser-friendly federated loginTo login using a federated provider, I currently see this:
![Screenshot_2020-03-20_at_14.57.44](/uploads/f8d0688972779d327d513c066d541b3c/Screenshot_2020-03-20_at_14.57.44.png)
Unfortunately login with email isn't possible, because we c...To login using a federated provider, I currently see this:
![Screenshot_2020-03-20_at_14.57.44](/uploads/f8d0688972779d327d513c066d541b3c/Screenshot_2020-03-20_at_14.57.44.png)
Unfortunately login with email isn't possible, because we can't guarantee that the email provider is the same as the OIDC provider, and we discover the OIDC provider using the input to this field (user@oidcproviderurl)
I think a lot of users won't know what a webfinger-id is, or what an OIDC provider is. An example could be added statically to this form ("e.g. yourusername@yourprovider.com")
Maybe we could also support a new setting which could be used to provide an optional context-specific example, e.g. `WEBFINGERID_EXAMPLE='yourusername@happy-dev.fr'`
@Rachel what do you think?https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/47Bad practice: validating username in the save()2020-04-16T18:44:38+02:00Jean-Baptiste PasquierBad practice: validating username in the save()Related: https://git.startinblox.com/applications/sib-app/issues/424#note_23457
Related lines: https://git.startinblox.com/djangoldp-packages/djangoldp-account/blob/3b4a90fa81378fafc9ad1da2d7605d9b52e4ea59/djangoldp_account/models.py#L9...Related: https://git.startinblox.com/applications/sib-app/issues/424#note_23457
Related lines: https://git.startinblox.com/djangoldp-packages/djangoldp-account/blob/3b4a90fa81378fafc9ad1da2d7605d9b52e4ea59/djangoldp_account/models.py#L95-100
As a quick fix, we merged these. But we'll need, at some point, to understand why we have this behavior and it may need a rework here.https://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/45Login with https://host/users/me/ format2021-05-18T12:34:11+02:00Jean-Baptiste PasquierLogin with https://host/users/me/ formatFollowing #73 , I should also be able to provide a OP hosted on another DjangoLDP server and login with itFollowing #73 , I should also be able to provide a OP hosted on another DjangoLDP server and login with ithttps://git.startinblox.com/djangoldp-packages/djangoldp-account/-/issues/42Redirection for federated users2020-04-16T18:44:37+02:00Calum MackervoyRedirection for federated usersWhen doing federated login, I end up here
![Screenshot_2020-03-17_at_09.04.38](/uploads/58c29260dac237e3f8d485f3ed3704fe/Screenshot_2020-03-17_at_09.04.38.png)
This is because my `redirect_default_uri` isn't set to anything on create us...When doing federated login, I end up here
![Screenshot_2020-03-17_at_09.04.38](/uploads/58c29260dac237e3f8d485f3ed3704fe/Screenshot_2020-03-17_at_09.04.38.png)
This is because my `redirect_default_uri` isn't set to anything on create user
Possibly this could be set during the login process, or some `DEFAULT_REDIRECT_DEFAULT_URI` could be set on the server