Custom Query (1173 matches)
Results (130 - 132 of 1173)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #218 | fixed | Announce only mailing list | ||
| Description |
I'd like people to be able to get news from us without comments. The target is press and other busy, but interested, people who would get notes when we blog and **occasional** press type email from me. If there's an off the rack way to have the blogs contents converted via html2text or using a rss2email script, that's cool but otherwise I will write a 1-2 sentence abstract and include the blog link. I'd be the only poster on this list. People who sign up for it can't reply to the list. In the nitty gritty of permissions, it probably makes sense for Will and Chris to be able to post, but in practice, I don't picture you ever needing to post to that list. Deb |
|||
| #363 | wontfix | Apache FCGI documentation In Manual | ||
| Description |
|
|||
| #710 | wontfix | Application-specific passwords | ||
| Description |
BackgroundOAuth requires an OAuth client to be registered with the server before any user can be asked to authorise the client to access a resource. This model makes sense for a centralised service provider, because authors of OAuth client applications only have to register their application once. For a decentralised service like MediaGoblin where there are many independent installations, the requirement to register a client becomes an obstacle. ExampleIf I had a web application that allowed my users to link their MediaGoblin accounts in order to upload pictures through my web application to their MediaGoblin collections, I would have to register my application as a client on every MediaGoblin installation that I want to support. This doesn't scale. ProposalOAuth doesn't seem to be designed to cover this use case. Hence I propose to implement application-specific API tokens. If a MediaGoblin user wanted to allow my web application to act on her behalf through the API, she would generate an API token for my web application and store the token with her account on my web application. My application can then use this token to perform uploads as the MediaGoblin user until the user decides to revoke the token. A user could thus grant external applications limited access to their account by generating a new application-specific password. The application could authenticate against the MediaGoblin server by providing the user's username and the application-specific password. (Something like that is used by Google when two factor authentication is enabled for Gmail and one needs a simple password to authenticate one's email client with the server.) As I need something like that, I volunteer to work on implementing this if it turns out to be a good idea. |
|||
