Re: [Python-Dev] Pre-PEP: Redesigning extension modules
Antoine Pitrou, 06.09.2013 07:43: > Proxying wrapper? We shouldn't need that kind of tricks. The advantage is that it's controlled by the loader, and transparent to the module itself. Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] windows file closing race condition?
On Fri, 06 Sep 2013 06:50:07 +0100 Chris Withers wrote: > > So, from my perspective, I'm either looking at a bug in shutil.rmtree > (which would be trying to delete a directory before deleting its content > or failing to delete a file but ignoring an error) or the file object, > when being used as a context manager, going through __exit__ without > closing the file and releasing the handle. It seems someone forgot to remove the following snippet from FileIO.__exit__: if random.random() > 0.0001: # Sometimes we leave the fd open, to annoy Chris os.close(self.fd) > This happens very infrequently, the OS is Windows 7 and the filesystem > is NTFS, if that helps... It should help indeed: http://blogs.msdn.com/b/oldnewthing/archive/2012/09/07/10347136.aspx :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Redesigning extension modules
On Mon, Sep 2, 2013 at 2:16 AM, Antoine Pitrou wrote: > I think the biggest challenge here is to propose an API that's simple > and easy to use (i.e. that doesn't make extension module writing more > complicated than it currently is). > +1 > > The basic concept of putting custom module objects in sys.modules is > sound, IMHO. > > As for "extension module as a wrapper", though, it shounds like the > kind of complication I would personally prefer to stay away from. Also, > it would make extension modules less like Python modules, rather than > more. > It all depends on how useful it would be to be able to safely reload extension modules from their files. -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Redesigning extension modules
On Sat, Aug 31, 2013 at 1:16 PM, Stefan Behnel wrote: > Nick Coghlan, 31.08.2013 18:49: > > This is actually my primary motivation for trying to improve the > > "can this be reloaded or not?" aspects of the loader API in PEP 451. > > I assume you mean that the extension module would be able to clearly signal > that it can't be reloaded, right? I agree that that's helpful. If you're > wrapping a C library, then the way that library is implemented might simply > force you to prevent any attempts at reloading the wrapper module. But if > reloading is possible at all, it would be even more helpful if we could > make it really easy to properly support it. > When loader.exec_module() gets called, it should raise ImportError if the module does not support reloading. -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] windows file closing race condition?
Hi All, Continuous testing is a wonderful thing when it comes to finding weird edge case problems, like this one: http://jenkins.simplistix.co.uk/job/testfixtures-tox/COMPONENTS=zc,PYTHON=3.3,label=windows/149/testReport/junit/testfixtures.tests.test_tempdirectory/TempDirectoryTests/test_check_all_tuple/ File "C:\Jenkins\workspace\testfixtures-tox\e8666d4e\.tox\3.3-zc\lib\site-packages\testfixtures\tempdirectory.py", line 323, in __exit__ self.cleanup() File "C:\Jenkins\workspace\testfixtures-tox\e8666d4e\.tox\3.3-zc\lib\site-packages\testfixtures\tempdirectory.py", line 78, in cleanup rmtree(self.path) File "C:\Jenkins\workspace\testfixtures-tox\e8666d4e\.tox\3.3-zc\lib\shutil.py", line 460, in rmtree return _rmtree_unsafe(path, onerror) File "C:\Jenkins\workspace\testfixtures-tox\e8666d4e\.tox\3.3-zc\lib\shutil.py", line 362, in _rmtree_unsafe _rmtree_unsafe(fullname, onerror) File "C:\Jenkins\workspace\testfixtures-tox\e8666d4e\.tox\3.3-zc\lib\shutil.py", line 371, in _rmtree_unsafe onerror(os.rmdir, path, sys.exc_info()) File "C:\Jenkins\workspace\testfixtures-tox\e8666d4e\.tox\3.3-zc\lib\shutil.py", line 369, in _rmtree_unsafe os.rmdir(path) OSError: [WinError 145] The directory is not empty: 'c:\\users\\jenkins\\appdata\\local\\temp\\tmpkeg4d7\\a' I'm 99% certain my code is correct here, the only place I open files for writing in that directory is here: https://github.com/Simplistix/testfixtures/blob/master/testfixtures/tempdirectory.py#L275 So, from my perspective, I'm either looking at a bug in shutil.rmtree (which would be trying to delete a directory before deleting its content or failing to delete a file but ignoring an error) or the file object, when being used as a context manager, going through __exit__ without closing the file and releasing the handle. This happens very infrequently, the OS is Windows 7 and the filesystem is NTFS, if that helps... Any ideas? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Redesigning extension modules
On Sat, Aug 24, 2013 at 10:12 PM, PJ Eby wrote: > I haven't had a chance to address this on the import-sig discussion > yet about ModuleSpec, but I would like to just mention that one > property of the existing module system that I'm not sure either this > proposal or the ModuleSpec proposal preserves is that it's possible to > implement lazy importing of modules using standard reload() semantics. > > My "Importing" package offers lazy imports by creating module objects > in sys.modules that are a subtype of ModuleType, and use a > __getattribute__ hook so that trying to use them fires off a reload() > of the module. Because the dummy module doesn't have __file__ or > anything else initialized, the import system searches for the module > and then loads it, reusing the existing module object, even though > it's actually only executing the module code for the first time. > > That the existing object be reused is important, because once the > dummy is in sys.modules, it can also be imported by other modules, so > references to it can abound everywhere, and we wish only for it to be > loaded lazily, without needing to trace down and replace all instances > of it. This also preserves other invariants of the module system. > > Anyway, the reason I was asking why reloading is being handled as a > special case in the ModuleSpec proposal -- and the reason I'm curious > about certain provisions of this proposal -- is that making the > assumption you can only reload something with the same > spec/location/etc. it was originally loaded with, and/or that if you > are reloading a module then you previously had a chance to do things > to it, doesn't jibe with the way things work currently. > That is to say, in the pure PEP 302 world, there is no special status > for "reload" that is different from "load" -- the *only* thing that's > different is that there is already a module object to use, and there > is *no guarantee that it's a module object that was initialized by the > loader now being invoked*. > In Python 3.3 (#13959) import.reload() was updated to reuse a module's __loader__, which must now be set. If __loader__ is not set, you get an AttributeError. If that's a problem we can create a tracker issue and discuss there. In Python 3.4 imp.reload() is just an alias to importlib.reload(), but it works basically the same. With ModuleSpec things won't work that differently. If you reload such a module as you described, it will look for __spec__ and call it's reload() method. If __spec__ is not set, you get an AttributeError. It wouldn't be that hard to build a spec from the module if need be and then use that. -eric > AFAICT both this proposal and the ModuleSpec one are making an invalid > assumption per PEP 302, and aren't explicitly proposing to change the > status quo: they just assume things that aren't actually assured by > the prior specs or implementations. > > So, for example, this extension module proposal needs to cover what > happens if an extension module is reloaded and the module object is > not of the type or instance it's expecting. Must it do its own > checking? Error handling? Will some other portion of the import > system be expected to handle it? > > For that matter, what happens (in either proposal) if you reload() a > module which only has a __name__, and no other attributes? I haven't > tested with importlib, but with earlier Pythons this results in a > standard module search being done by reload(). But the ModuleSpec > proposal and this one seem to assume that a reload()-ed module must > already be associated with a loader, location, and/or spec. > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Redesigning extension modules
On Thu, 5 Sep 2013 23:26:31 -0600 Eric Snow wrote: > On Sat, Aug 24, 2013 at 7:07 AM, Stefan Behnel wrote: > > > PEP 3121 would no longer be necessary. Extension types can do all we need. > > No more special casing of modules, that was the idea. > > > > One nice thing about PEP 3121 is the addition of md_state to module objects > to store internal module state. Wouldn't we be better served by improving > the related API rather than abandoning it? md_state isn't a PyObject and therefore its lifetime management is quirky (as Py_buffer, same bad idea). So I'd be happy for it to disappear from the next API. > This, coupled with the PEP 451-compatible API and with a proxying wrapper, > would go a long way to various "reloading" issues that extension modules > have. Proxying wrapper? We shouldn't need that kind of tricks. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Redesigning extension modules
On Sat, Aug 24, 2013 at 7:07 AM, Stefan Behnel wrote: > PEP 3121 would no longer be necessary. Extension types can do all we need. > No more special casing of modules, that was the idea. > One nice thing about PEP 3121 is the addition of md_state to module objects to store internal module state. Wouldn't we be better served by improving the related API rather than abandoning it? If md_state were the home for all mutable internal state then load/reload could focus directly on just md_state and md_dict and not worry about other internal state, since all remaining state would be immutable (refcounts notwithstanding). If the API made this easier then we could leverage the strengths of PEP 3121 to make loading safer and more independent. Of course, we could certainly go the other way and actively discourage mutable internal state... This, coupled with the PEP 451-compatible API and with a proxying wrapper, would go a long way to various "reloading" issues that extension modules have. On Sun, Aug 25, 2013 at 5:54 AM, Stefan Behnel wrote: > (regarding reloading into the existing module's namespace) > > I'm not sure this can be done in general. What if the module has threads > running that access the global state? In that case, reinitialising the > module object itself would almost certainly lead to a crash. > > And what if you do "from extmodule import some_function" in a Python > module? Then reloading couldn't replace that reference, just as for normal > Python modules. Meaning that you'd still have to keep both modules properly > alive in order to prevent crashes due to lost global state of the imported > function. > > The difference to Python modules here is that in Python code, you'll get > some kind of exception if state is lost during a reload. In C code, you'll > most likely get a crash. > > How would you even make sure global state is properly cleaned up? Would you > call tp_clear() on the module object before re-running the init code? Or > how else would you enable the init code to do the right thing during both > the first run (where global state is uninitialised) and subsequent runs > (where global state may hold valid state and owned Python references)? > > Even tp_clear() may not be enough, because it's only meant to clean up > Python references, not C-level state. Basically, for reloading to be > correct without changing the object reference, it would have to go all the > way through tp_dealloc(), catch the object at the very end, right before it > gets freed, and then re-initialise it. > Right. It would probably require a separate `PyImportInitializeState_(PyObject *mod)` and/or some API that helps make it easier to manage mutable internal module state (on md_state). On Sun, Aug 25, 2013 at 6:36 AM, Stefan Behnel wrote: > PJ Eby, 25.08.2013 06:12: > > My "Importing" package offers lazy imports by creating module objects > > in sys.modules that are a subtype of ModuleType, and use a > > __getattribute__ hook so that trying to use them fires off a reload() > > of the module. > > I wonder if this wouldn't be an approach to fix the reloading problem in > general. What if extension module loading, at least with the new scheme, > didn't return the module object itself and put it into sys.modules but > created a wrapper that redirects its __getattr__ and __setattr__ to the > actual module object? That would have a tiny performance impact on > attribute access, but I'd expect that to be negligible given that the usual > reason for the extension module to exist is that it does non-trivial stuff > in whatever its API provides. Reloading could then really create a > completely new module object and replace the reference inside of the > wrapper. > > That way, code that currently uses "from extmodule import xyz" would > continue to see the original version of the module as of the time of its > import, and code that just did "import extmodule" and then used attribute > access at need would always see the current content of the module as it was > last loaded. I think that, together with keeping module global state in the > module object itself, would nicely fix both cases. > At first blush I like this. -eric p.s. Bear with me if I've missed something in the thread. I'm slogging through a backlog of email ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/13 20:45, Eli Bendersky wrote: > PS: I use "http://www.jcea.es/"; as my OpenID identity, and I > delegate the actual service to "myOpenID". I can switch delegation > trivially. > > http://bugs.python.org/?@action=openid_login&provider=Google Sorry, Google, Facebook, Twitter, etc., are not acceptable OpenID providers for me. I should have made that point in my original email. My excuses. Any other suggestion? - -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQCVAwUBUik2Z5lgi5GaxT1NAQJEtQP+NdOaMbAB4LzgsUfoL1yelPcYA8wg2rnd WjM7IEsfcs/3NFrmpg9XxjJqSwoxgqW8NqpcQLapGSUdqUxMrhYz3xUnXzSUmM75 IwxUWlTuVVQkscRWwrmIjqMWD20EI3KtmGBtCH5J1Tnmb1EeTH4+wrtpBcl3hBUi Ph8+Afy+E6w= =VkCq -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/13 22:29, Oleg Broytman wrote: > I have seen exactly 0 (zero) sites that support Persona. Can you > point me? "Python España" (Python Spain) association is going to provide Persona Only login. Deployment in four weeks. - -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQCVAwUBUik1uZlgi5GaxT1NAQIA3wP/eH0HA+gxa/9c1S679lmC7GVoBqahWyWS mmOnIg170MaozIxyjgLruReTKdnfhcFa/QxxWLpS7brGenOSA1UCXdOhRHRTpf5y JMtQ/f1pmS3sdjEIal2F6Fm1Dt1i6YFZr813j9hdzVHgcx96PuxTx5UVO3LpAAkf +edD8PBn3eM= =y1Ri -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/13 23:56, Oleg Broytman wrote: > Well, I can only use services that are available, not those that > are promised. If python.org grows support for Persona -- who will > be my provider and for what price? I am not going to install and > manage additional software on my servers -- I don't want to be my > own provider, I have enough job already. If your email provider is not supporting Persona, the automatic fallback is Mozilla, a non-profit, free web, I care about your privacy, organization. - -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQCVAwUBUik1Y5lgi5GaxT1NAQLKjwP9EXXmMTVORDPOCK5ByBfrwveL71nG/1IJ oTc0ZUjZPMp/JD2UBnibEUIhxJHtmAkTsuMTmNsSbzqx6F74n9zYokfMK4Y0iscC 2EpqDe7lcAzEjJXpIa93A/K8/fh3gaufWHAXND3Ynr7gMdlLkn9jRiXoVMHHX3Sm lEIX/47kzlI= =4+OP -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/13 22:36, Oleg Broytman wrote: > There was no demise. Because there was no take-off. OpenID was > never popular. I can remember a very limited set of major sites > that allow login using OpenID: SourceForge, LiveJournal, BitBucket. > The first two I remember a day where OpenID was the ONLY authentication method in StackOverflow. - -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQCVAwUBUik1Iplgi5GaxT1NAQKHGQP/ayFi3hs5CWwlNCciFguNkUesQBfRaPFF TxHrloNM2Uo9wB2dt2oAVhAQnGSTw3lIYoRMzhk5+tfx4Bn16QVPiDXnbotO5xqn QkAH3ZE9q9/YTDDqPJPFXHP/7eoQwk9Ou4LrTJk97ofp0DM7JcfVm3W0Sys53wEQ ddwoNkrIk/s= =vFd+ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/13 21:53, Ben Finney wrote: > My own take is that most people choose convenience and expedience > over security and freedom, hence Facebook and Twitter and Google > have taken over the online identity game instead of a federated > identity system. That is one of the Persona improvements: If your email provider is not supporting it, you can still use your email with "persona" (thru Mozilla servers). If you provider support OAUTH authentication (let say, Facebook, twitter, Google), You can use that identity to prove your identity to Mozilla, and Mozilla to prove your email ID to any Persona consumer. In the process, you get privacy (facebook doesn't know where are you using authentication, beside Mozilla). Being a Persona provider is easy, being a verifier is trivial. An interesting property of Persona is that if its popularity grows, it becomes decentralized "automágically". Anyway, I was asking for alternative OpenID providers, not to open a debate about single sign on methods :). - -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQCVAwUBUikzWZlgi5GaxT1NAQJMbgP/enbARAwUiDXzJ9PkBmvlAi/OrhXrrXwE Vf1f6XHab+ERyJ6kj1V5yz6F0D0zxl6s7GL+abz7P0JEdGEGMfEJc+aK15HM2r3b LAm9k5ofe+ysdJx0HEd/V6/viqAeK7medb5Hh3xNwxbY6qRe4VkXbAvc0KQuo7eR 1Uf005ibUT8= =i0/D -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
Barry Warsaw writes: > On Sep 06, 2013, at 12:36 AM, Oleg Broytman wrote: > > You cannot login using OpenID to most interesting popular sites. > >GMail? No. Twitter? No. Facebook? FriendFeed? identi.ca? No, no, no. > > I'd be surprised if you ever saw the big social networking sites support > OpenID or Persona. They want to own that space themselves, so probably have > no business incentive to support 3rd party systems. Quite the reverse, unfortunately. That's why *those* sites *all* appear on most sites that support OpenID. They're not going to delegate to each other until they are forced to. > We're open source, and I think it benefits our mission to support open, > decentralized, and free systems like OpenID and Persona. Thus speaks an employee of yet another Provider-That-Won't-Accept-My- Third-Party-Credentials. Sorry, Barry, but you see the problem: Unfortunately, we can't do it alone. What needs to happen is there needs to be a large network of sites that support login via O-D-F systems like OpenID and Persona. Too many of the sites I use (news sources, GMail, etc) don't support them and my browser manages my logins to most of them, so why bother learning OpenID, and then setting it up site by site? I'm not against it, but it's quixotic (and therefore valuable). One reason that OpenID and Persona fail to achieve penetration is that they overstate their mission. A protocol that any email provider can support is a protocol that provides authentication without identification (imagine what havoc Dogbert could wreak with his own Persona provider), and therefore cannot be used in authorization (except trivially). Think ident (port tcp/113). And most general- audience sites that want to provide high-quality "Web 2.0" service are going to start by asking for your demographics. It's probably at least as effective as CAPTCHA for classifying mammals and 'bots, too! The reason that the "big" providers can take advantage of these protocols as providers without reciprocating as clients is that identities on these sites are very valuable to at least 95% of people who use them (that may or may not correspond to as much as 50% of the accounts). Losing your Facebook site for abuse of TOS is very costly: you can't even contact your "circle" easily. Nor do you want multiple logins on one of these sites, because that will double the amount of spam they send you. Bottom line: A login via Facebook-provided OpenID means that the login is unlikely to perform random mischief. Of course, those issues are easy to deal with if you have even a bit of Internet savvy. So sites still have to worry about a deliberate attack from a Facebook user, but a serious intruder has many ways to get in the front door, so you need to lock up your Waterford crystal and Noritake china anyway whether you support global ID logins or not. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 05, 2013 at 05:29:07PM -0400, Barry Warsaw wrote: > I don't want my choice to be log into Facebook or manage a slew of passwords. The last part is unavoidable. I regularly login to LiveJournal, Twitter, SourceForge, BitBucket, Gitorious, GitHub and to hundreds of other sites -- blogs, torrents, web shops. I already manage hundreds of passwords. OpenID promised to save me from that and failed. Do you think Persona would succeed in this regard (saved me from managing all those passwords)? And if not -- what are the benefits? I already manage hundreds of passwords -- two or three additional passwords for bugs.python.org, wiki.python.org and so on don't make the situation worse. IMO the very idea of single sign-on in the open web is meaningless. > But I'm not volunteering to do the work, so I don't get to decide. I'm just > stating that I think our principle should be that you *can* (not *must*) use > free and open services to access our resources. Well, I can only use services that are available, not those that are promised. If python.org grows support for Persona -- who will be my provider and for what price? I am not going to install and manage additional software on my servers -- I don't want to be my own provider, I have enough job already. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Sep 5, 2013, at 5:56 PM, Oleg Broytman wrote: > On Thu, Sep 05, 2013 at 05:29:07PM -0400, Barry Warsaw > wrote: >> I don't want my choice to be log into Facebook or manage a slew of passwords. > > The last part is unavoidable. I regularly login to LiveJournal, > Twitter, SourceForge, BitBucket, Gitorious, GitHub and to hundreds of > other sites -- blogs, torrents, web shops. I already manage hundreds of > passwords. OpenID promised to save me from that and failed. Do you think > Persona would succeed in this regard (saved me from managing all those > passwords)? And if not -- what are the benefits? I already manage > hundreds of passwords -- two or three additional passwords for > bugs.python.org, wiki.python.org and so on don't make the situation > worse. > IMO the very idea of single sign-on in the open web is meaningless. > >> But I'm not volunteering to do the work, so I don't get to decide. I'm just >> stating that I think our principle should be that you *can* (not *must*) use >> free and open services to access our resources. > > Well, I can only use services that are available, not those that are > promised. If python.org grows support for Persona -- who will be my > provider and for what price? I am not going to install and manage > additional software on my servers -- I don't want to be my own provider, > I have enough job already. Theoretically whoever runs the domain for your email address (since Persona uses email as your identifier). In order to make it work as a stop gap they also have more openid like idP's which they run a major one (that also offers a "bridge" to make things like Gmail work on Persona without needing to register for anything else). > > Oleg. > -- > Oleg Broytmanhttp://phdru.name/p...@phdru.name > Programmers don't die, they just GOSUB without RETURN. > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a new tracemalloc module to trace memory allocations
2013/8/31 Gregory P. Smith : > Think of the possibilities, you could even setup a test runner to > enable/disable before and after each test, test suite or test module to > gather narrow statistics as to what code actually _caused_ the allocations > rather than the ultimate individual file/line doing it. It may be used with "-m test -R" to detect memory leaks, you need to repeat a test. > Taking that further: file and line information is great, but what if you > extend the concept: could you allow for C API or even Python hooks to gather > additional information at the time of each allocation or free? for example: > Gathering the actual C and Python stack traces for correlation to figure out > what call patterns lead allocations is powerful. I modified the PEP 454 and the implementation. By default, tracemalloc only stores 1 "frame" instance (filename and line number). But you can now use tracemalloc.set_number_frame(10) to store 10 frames per memory allocation. Don't store too much frames, remember that tracemalloc traces all Python memory allocations! So when Python allocates 1 byte, tracemalloc may need to allocate 1000 bytes to store the trace... tracemalloc cannot get the C traceback. It was discussed in the design of the PEP 445 (Add new APIs to customize Python memory allocators) how to pass the C filename and line number. It was decided to not add them to have a simpler API. In general, a C function is binded to a Python function. Knowing the Python function should be enough. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 05, 2013 at 10:25:22PM +0400, Oleg Broytman wrote: > On Thu, Sep 05, 2013 at 02:16:29PM -0400, Donald Stufft > wrote: > > > > On Sep 5, 2013, at 2:12 PM, Oleg Broytman wrote: > > > I used to use myOpenID and became my own provider using poit[1]. > > > These days I seldom use OpenID -- there are too few sites that allow > > > full-featured login with OpenID. The future lies in OAuth 2.0. > > > > The Auth in OAuth stands for Authorization not Authentication. > >There is no authorization without authentication, so OAuth certainly > performs authentication: http://oauth.net/core/1.0a/#anchor9 , > http://tools.ietf.org/html/rfc5849#section-3 > Sortof The way OAuth looks to me, it's designed to prove that a given client is authorized to perform an action. It's not designed to prove that the given client is a specific person. In some cases, you really want to know the latter and not merely the former. So I think in these situations Donald's separation of Authz and Authn makes sense. -Toshio pgppLjnxYjd1p.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a new tracemalloc module to trace memory allocations
2013/9/1 Nick Coghlan : > +1 from me for both tracemalloc and failmalloc in the same vein as > faulthandler (and using similar API concepts to faulthandler). > > While I like the flat top level naming structure, we should clearly document > these as implementation dependent runtime services. Other implementations > may not provide them at all, and even if they do, many details will likely > be different. > > The gc module may even fall into the same category. I updated the PEP 454 to mention that tracemalloc has been written for CPython. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Sep 06, 2013, at 12:36 AM, Oleg Broytman wrote: > You cannot login using OpenID to most interesting popular sites. >GMail? No. Twitter? No. Facebook? FriendFeed? identi.ca? No, no, no. I'd be surprised if you ever saw the big social networking sites support OpenID or Persona. They want to own that space themselves, so probably have no business incentive to support 3rd party systems. We're open source, and I think it benefits our mission to support open, decentralized, and free systems like OpenID and Persona. -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Sep 06, 2013, at 01:09 AM, Oleg Broytman wrote: >I will change my mind when Google and GitHub start using them. Neither Google nor GitHub are free or open. Bitbucket and Facebook aren't either. I'm not saying they're bad services because of that of course, but I don't want to have to rely on any of them to access python.org resources, and I don't want my choice to be log into Facebook or manage a slew of passwords. But I'm not volunteering to do the work, so I don't get to decide. I'm just stating that I think our principle should be that you *can* (not *must*) use free and open services to access our resources. -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: PEP 454: Add a new tracemalloc module
2013/9/5 Alexander Belopolsky : > Please mention that this API is similar to that of faulthandler and add a > link to faulthandler docs. Done. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 05, 2013 at 04:58:19PM -0400, Tres Seaver wrote: > On 09/05/2013 04:29 PM, Oleg Broytman wrote: > > I have seen exactly 0 (zero) sites that support Persona. Can you point > > me? > > - From the "Mozilla Identity" blog: > > - - https://webmaker.org/ > - - http://bornthiswayfoundation.org/ > - - http://firebase.com/ > - - https://orionhub.org/ > - - http://ting.com/ > - - http://www.gnu.org/software/mailman/ > - - http://discourse.org/ > - - https://dailycred.com/ Thank you! Never heard of these sites. Well, I saw WebMaker once, but it's a Mozilla site, no wonder it supports Persona. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/05/2013 04:33 PM, Glenn Linderman wrote: > On 9/5/2013 1:30 PM, Tres Seaver wrote: >> +1 for supporting Persona as an alternative to OpenID on all >> *.python.org servers. > > Is there a Python implementation of Persona I can install on my web > server? - - https://readthedocs.org/projects/django-browserid/ - - https://pyramid_persona.readthedocs.org/en/latest/ Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIo8SMACgkQ+gerLs4ltQ57xgCfT2xVkJfMtuDjmed6jlhfsD8I fxMAoNHT69tbi3iKtpkyEcSY0lwJosqc =TTJ8 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
There's some sample Python code here: https://developer.mozilla.org/en-US/docs/Mozilla/Persona/Quick_Setup The API is so simple something generic like requests suffices. 2013/9/5 Glenn Linderman : > On 9/5/2013 1:30 PM, Tres Seaver wrote: > > +1 for supporting Persona as an alternative to OpenID on all *.python.org > servers. > > > Is there a Python implementation of Persona I can install on my web server? > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/benjamin%40python.org > -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
> Whether a given site chooses to authroize an > authenticated-but-otherwise-unknown user to do anything meaningful is > logically distinct. But the least they could have done was pick a demo site that didn't do exactly what they contend you shouldn't need to do: cough up all sorts of personal information to use their site. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 5, 2013 at 10:33 PM, Glenn Linderman wrote: > Is there a Python implementation of Persona I can install on my web server? If you mean to use your web server as an Identity Provider, try this: https://bitbucket.org/djc/persona-totp It currently only implements TOTP-based authentication (i.e. no passwords), but it should be easy to add a password or 2FA-mode if you'd prefer that. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 5, 2013 at 10:57 PM, Donald Stufft wrote: > Not that it changes this statement at all but you wouldn't expect to see a > Persona login > for gmail as persona solves the problem that people don't think of urls as > personal > identifiers by replacing it with emails. So Gmail would be the Persona IdP And actually you can already trivially login with your GMail account on any Persona-based Relying Party (that is, a site that uses Persona to authenticate you). This is because one of the nice parts of the current implementation of Persona is that Mozilla has implemented bridges that allow GMail and Yahoo addresses to be authenticated via their respective OAuth implementations, such that you don't need to setup an account at Mozilla's fallback IdP (which acts as an Identity Provider for email addresses that don't currently have an IdP available to them). Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, 5 Sep 2013 15:40:44 -0400 Barry Warsaw wrote: > On Sep 05, 2013, at 09:07 PM, Antoine Pitrou wrote: > > >Which sites exactly? I can login to BitBucket and *.python.org using > >OpenID, not Persona. > > I think Persona is just too new to see it around much yet. Or maybe Mozilla > needs better PR. Well, OpenID at least got some publicity since it appeared. Persona is almost unknown at this point (though it was publicly launched two years ago, according to Wikipedia). Comparing the size of the respective Wikipedia pages actually tells quite a bit: http://en.wikipedia.org/wiki/OpenID http://en.wikipedia.org/wiki/Mozilla_Persona Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 5, 2013 at 4:29 PM, Oleg Broytman wrote: > I have seen exactly 0 (zero) sites that support Persona. Can you > point me? We have an internal app that uses Persona, but we did that mostly to play with it. I've not run across any sites that use Persona in the wild, either. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 05, 2013 at 02:07:11PM -0500, Skip Montanaro wrote: > >> OpenID lived a short life and died a quiet death. I'm afraid Persona > >> wouldn't live even that much. Dead-born idea, in my so humble opinion. > > > I was completely unaware of OpenID's demise. There was no demise. Because there was no take-off. OpenID was never popular. I can remember a very limited set of major sites that allow login using OpenID: SourceForge, LiveJournal, BitBucket. The first two in the list allow limited login. BitBucket doesn't allow even that. They only allow full-featured login if you have already created an account and linked your OpenID URL with that account. You cannot login using OpenID to most interesting popular sites. GMail? No. Twitter? No. Facebook? FriendFeed? identi.ca? No, no, no. Small uninteresting blogs? Yes, but who cares? Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Sep 5, 2013, at 4:53 PM, Barry Warsaw wrote: > On Sep 06, 2013, at 12:36 AM, Oleg Broytman wrote: > >> You cannot login using OpenID to most interesting popular sites. >> GMail? No. Twitter? No. Facebook? FriendFeed? identi.ca? No, no, no. > > I'd be surprised if you ever saw the big social networking sites support > OpenID or Persona. They want to own that space themselves, so probably have > no business incentive to support 3rd party systems. Not that it changes this statement at all but you wouldn't expect to see a Persona login for gmail as persona solves the problem that people don't think of urls as personal identifiers by replacing it with emails. So Gmail would be the Persona IdP > > We're open source, and I think it benefits our mission to support open, > decentralized, and free systems like OpenID and Persona. > > -Barry > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On 9/5/2013 1:30 PM, Tres Seaver wrote: +1 for supporting Persona as an alternative to OpenID on all *.python.org servers. Is there a Python implementation of Persona I can install on my web server? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 05, 2013 at 04:53:18PM -0400, Barry Warsaw wrote: > On Sep 06, 2013, at 12:36 AM, Oleg Broytman wrote: > > You cannot login using OpenID to most interesting popular sites. > >GMail? No. Twitter? No. Facebook? FriendFeed? identi.ca? No, no, no. > > I'd be surprised if you ever saw the big social networking sites support > OpenID or Persona. They want to own that space themselves, so probably have > no business incentive to support 3rd party systems. But of course! And that IMO spells the end of the feature. Things that aren't available for millions seldom are available for a few, and if they are -- they are available for big price. > We're open source, and I think it benefits our mission to support open, > decentralized, and free systems like OpenID and Persona. But they also have disadvantages. Implementing such a major feature is a significant burden to sysadmins and is an additional vein for security breaches. That said, I don't mind if pydotorg would get such features. If FSF pays salaries and admins are willing to work -- no objections from me. But I am not going to use it. What gain if I can login to one site? I will change my mind when Google and GitHub start using them. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/05/2013 04:29 PM, Oleg Broytman wrote: > On Thu, Sep 05, 2013 at 02:50:44PM -0400, Donald Stufft > wrote: >> On Sep 5, 2013, at 2:43 PM, Oleg Broytman wrote: >>> On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft >>> wrote: Persona is the logical successor to OpenID. >>> >>> OpenID lived a short life and died a quiet death. I'm afraid >>> Persona wouldn't live even that much. Dead-born idea, in my so >>> humble opinion. >> >> I don't think there's much evidence to support this. I'm seeing more >> sites support Persona not less. It solves some of the major problems >> with OpenID. > > I have seen exactly 0 (zero) sites that support Persona. Can you point > me? - From the "Mozilla Identity" blog: - - https://webmaker.org/ - - http://bornthiswayfoundation.org/ - - http://firebase.com/ - - https://orionhub.org/ - - http://ting.com/ - - http://www.gnu.org/software/mailman/ - - http://discourse.org/ - - https://dailycred.com/ Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIo8GoACgkQ+gerLs4ltQ5OtACdEv/XvYKwGuFQESuLn+uBkNzm UUAAn2YY22+YL+tS0WhE+95tIb0USmV7 =cB96 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Offtopic: OpenID Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just received an email from my OpenID provider, "myOpenID", saying that they drop OpenID service next February. I wonder what other OpenID providers are used by other python-dev fellows. What are you using?. bugs.python.org admins could share some data? I agree than OpenID is (quite) dead, but I rather prefer OpenID to use user/pass. I have big hopes for Mozilla Persona, looking forward Python infrastructure support :). PS: I use "http://www.jcea.es/"; as my OpenID identity, and I delegate the actual service to "myOpenID". I can switch delegation trivially. - -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQCVAwUBUijAD5lgi5GaxT1NAQLH0wQAkKDORrAtfJFzzIHl3lHRp7GfxOzdqdNP uiuW65l/pas+p9+B0G6qR6EE2AAL7YPozcNF5AkmuGmxkpyn/JyUYKJcUWmUotpj V9Buz9jz3qpPuv7AlTnMbjBBQK4YTYenbdk2HgI41SVQHZHkU/+y4CL3Y1hWyJNo C8CCWfR0VlA= =YXIq -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 5, 2013 at 10:30 PM, Tres Seaver wrote: > +1 for supporting Persona as an alternative to OpenID on all *.python.org > servers. BTW, I'd be happy to assist with any Persona RP implementations for python.org services. The MDN docs are pretty good, I got my first RP going in just a few hours of looking at code (and you can probably do better if you're more into frontend webdev stuff). There's also ongoing work that will replace ReadTheDocs accounts with Persona support. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Sep 5, 2013, at 2:43 PM, Oleg Broytman wrote: > On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft > wrote: >> Persona is the logical successor to OpenID. > > OpenID lived a short life and died a quiet death. I'm afraid Persona > wouldn't live even that much. Dead-born idea, in my so humble opinion. I don't think there's much evidence to support this. I'm seeing more sites support Persona not less. It solves some of the major problems with OpenID. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, 05 Sep 2013 19:31:59 +0200 Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I just received an email from my OpenID provider, "myOpenID", saying > that they drop OpenID service next February. I wonder what other > OpenID providers are used by other python-dev fellows. I use a self-hosted SimpleID instance: > > What are you using?. bugs.python.org admins could share some data? > > I agree than OpenID is (quite) dead, but I rather prefer OpenID to use > user/pass. I have big hopes for Mozilla Persona, looking forward > Python infrastructure support :). > > PS: I use "http://www.jcea.es/"; as my OpenID identity, and I delegate > the actual service to "myOpenID". I can switch delegation trivially. > > - -- > Jesús Cea Avión _/_/ _/_/_/_/_/_/ > j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ > Twitter: @jcea_/_/_/_/ _/_/_/_/_/ > jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQCVAwUBUijAD5lgi5GaxT1NAQLH0wQAkKDORrAtfJFzzIHl3lHRp7GfxOzdqdNP > uiuW65l/pas+p9+B0G6qR6EE2AAL7YPozcNF5AkmuGmxkpyn/JyUYKJcUWmUotpj > V9Buz9jz3qpPuv7AlTnMbjBBQK4YTYenbdk2HgI41SVQHZHkU/+y4CL3Y1hWyJNo > C8CCWfR0VlA= > =YXIq > -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 05, 2013 at 02:50:44PM -0400, Donald Stufft wrote: > On Sep 5, 2013, at 2:43 PM, Oleg Broytman wrote: > > On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft > > wrote: > >> Persona is the logical successor to OpenID. > > > > OpenID lived a short life and died a quiet death. I'm afraid Persona > > wouldn't live even that much. Dead-born idea, in my so humble opinion. > > I don't think there's much evidence to support this. I'm seeing more sites > support Persona > not less. It solves some of the major problems with OpenID. I have seen exactly 0 (zero) sites that support Persona. Can you point me? Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
Skip Montanaro writes: > >> On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft > >> wrote: > >>> Persona is the logical successor to OpenID. > >> > >> OpenID lived a short life and died a quiet death. I'm afraid Persona > >> wouldn't live even that much. Dead-born idea, in my so humble opinion. > > > > I don't think there's much evidence to support this. I'm seeing more sites > > support Persona > > not less. It solves some of the major problems with OpenID. > > I was completely unaware of OpenID's demise. It has failed at its stated purpose, which was to obviate the need for services to provide their own ad hoc systems and allow users to consolidate their digital identities. This is evident by lookig at how few sites have added OpenID login in the past several years, and how many that once had it have dropped it. If you're unaware of that, I can only surmise you haven't been trying to log in with an OpenID to anything newer than about 2009. > Can someone point me to/provide an explanation? An explanation in terms of what? I can point you to punditry http://www.25hoursaday.com/weblog/2011/01/30/LearningFromOurMistakesTheFailureOfOpenIDAtomPubAndXMLOnTheWeb.aspx> and hand-wringing http://geekyschmidt.com/2011/01/31/openid-death-greatly-exaggerated>. My own take is that most people choose convenience and expedience over security and freedom, hence Facebook and Twitter and Google have taken over the online identity game instead of a federated identity system. > I much prefer using OpenID to login to a site than having to either > come up with yet another username/password which I will just forget, > or using Facebook or similar (I don't really trust them with my info). Agreed. Our preferences are not enough though. -- \ “Anyone who believes exponential growth can go on forever in a | `\finite world is either a madman or an economist.” —Kenneth | _o__) Boulding | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
> I think Persona is just too new to see it around much yet. Or maybe Mozilla > needs better PR. The Persona site touts: "Signing in using Persona requires only a valid email address; allowing you to provide personal information on as-needed basis, when and where you think it’s appropriate." They clearly need a better example site. They chose something called Voost. Sure enough, all I needed to enter was my Gmail address. That got me signed in, but then Voost asked me for a bunch of other personal information (name, gender, birthdate, etc), and wouldn't let me go any farther without that. :-/ Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/05/2013 03:52 PM, Skip Montanaro wrote: >> I think Persona is just too new to see it around much yet. Or maybe >> Mozilla needs better PR. > > The Persona site touts: "Signing in using Persona requires only a > valid email address; allowing you to provide personal information on > as-needed basis, when and where you think it’s appropriate." > > They clearly need a better example site. They chose something called > Voost. Sure enough, all I needed to enter was my Gmail address. That > got me signed in, but then Voost asked me for a bunch of other > personal information (name, gender, birthdate, etc), and wouldn't let > me go any farther without that. :-/ As sith OpenID, the key element to Persona is SSO: you can authenticate without needing to create / remember passwords for every site you visit. Whether a given site chooses to authroize an authenticated-but-otherwise-unknown user to do anything meaningful is logically distinct. +1 for supporting Persona as an alternative to OpenID on all *.python.org servers. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIo6ecACgkQ+gerLs4ltQ6gOwCgrIokRYnddNaNVIVPoY/M4d0k kKcAni6hxXQE4T4QMij3bQHAJwBFX1uW =9ZJP -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Sep 05, 2013, at 09:07 PM, Antoine Pitrou wrote: >Which sites exactly? I can login to BitBucket and *.python.org using >OpenID, not Persona. I think Persona is just too new to see it around much yet. Or maybe Mozilla needs better PR. -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Sep 05, 2013, at 11:33 AM, Toshio Kuratomi wrote: >Sortof The way OAuth looks to me, it's designed to prove that a given >client is authorized to perform an action. It's not designed to prove that >the given client is a specific person. In some cases, you really want to >know the latter and not merely the former. So I think in these situations >Donald's separation of Authz and Authn makes sense. This probably isn't the only application of these technologies, but I've always thought about OAuth as delegating authority to scripts and programs to act on your behalf. For example, you can write a script to interact with Launchpad's REST API, but before you can use the script, you have to interact with the web ui once (since your browser is trusted, presumably) to receive a token which the script can then use to prove that it's acting on your behalf. If at some point you stop trusting that script, you can revoke the token to disable its access, without having to reset your password. To me, OpenID is about logging into web sites using single-sign on. For example, once I've logged into Launchpad, I can essentially go anywhere that accepts OpenID, type my OpenID and generally not have to log in again (things like two-factor auth and such may change that interaction pattern). Or to summarize to a rough approximation: OpenID is for logins, OAuth is for scripts. Persona seems to fit the OpenID use case. You'd still want OAuth for scripting. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
>> On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft >> wrote: >>> Persona is the logical successor to OpenID. >> >> OpenID lived a short life and died a quiet death. I'm afraid Persona >> wouldn't live even that much. Dead-born idea, in my so humble opinion. > > I don't think there's much evidence to support this. I'm seeing more sites > support Persona > not less. It solves some of the major problems with OpenID. I was completely unaware of OpenID's demise. Can someone point me to/provide an explanation? I much prefer using OpenID to login to a site than having to either come up with yet another username/password which I will just forget, or using Facebook or similar (I don't really trust them with my info). Thx, Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, 5 Sep 2013 14:50:44 -0400 Donald Stufft wrote: > > On Sep 5, 2013, at 2:43 PM, Oleg Broytman wrote: > > > On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft > > wrote: > >> Persona is the logical successor to OpenID. > > > > OpenID lived a short life and died a quiet death. I'm afraid Persona > > wouldn't live even that much. Dead-born idea, in my so humble opinion. > > I don't think there's much evidence to support this. I'm seeing more sites > support Persona > not less. Which sites exactly? I can login to BitBucket and *.python.org using OpenID, not Persona. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 05, 2013 at 02:53:43PM -0400, Barry Warsaw wrote: > > This probably isn't the only application of these technologies, but I've > always thought about OAuth as delegating authority to scripts and programs to > act on your behalf. For example, you can write a script to interact with > Launchpad's REST API, but before you can use the script, you have to interact > with the web ui once (since your browser is trusted, presumably) to receive a > token which the script can then use to prove that it's acting on your behalf. > If at some point you stop trusting that script, you can revoke the token to > disable its access, without having to reset your password. > > To me, OpenID is about logging into web sites using single-sign on. For > example, once I've logged into Launchpad, I can essentially go anywhere that > accepts OpenID, type my OpenID and generally not have to log in again (things > like two-factor auth and such may change that interaction pattern). > > Or to summarize to a rough approximation: OpenID is for logins, OAuth is for > scripts. > > Persona seems to fit the OpenID use case. You'd still want OAuth for > scripting. > However, in some cases, Persona/OpenID can make more sense for scripts. For instance, if you have a script that is primarily interactive in nature, it may be better to have the user login via that script than to have an OAuth token laying around on the filesystem all the time (Contrariwise, if the script is primarily run from cron or similar, it's better to have a token with limited permissions laying around on the filesystem than your OpenID password ;-) It's probably also useful to point out that OAuth (because it was developed to let third party websites have limited permission to act on your behalf) is more paranoid than strictly required for many scripts where that "third-party" is a script that you've written running on a box that you control. If that's the main use case for your service, OAuth may not be a good fit for your authz needs. -Toshio pgpK1y9fAvp9j.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, 05 Sep 2013 19:31:59 +0200 Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I just received an email from my OpenID provider, "myOpenID", saying > that they drop OpenID service next February. I wonder what other > OpenID providers are used by other python-dev fellows. > > What are you using?. bugs.python.org admins could share some data? I use a self-hosted SimpleID instance: http://simpleid.koinic.net/ It works fine with python.org, except recent problems with PyPI for which I haven't had an answer yet: https://mail.python.org/pipermail/distutils-sig/2013-September/022583.html (sorry for the previous message, keyboard mishap) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft wrote: > Persona is the logical successor to OpenID. OpenID lived a short life and died a quiet death. I'm afraid Persona wouldn't live even that much. Dead-born idea, in my so humble opinion. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 5, 2013 at 10:31 AM, Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I just received an email from my OpenID provider, "myOpenID", saying > that they drop OpenID service next February. I wonder what other > OpenID providers are used by other python-dev fellows. > > What are you using?. bugs.python.org admins could share some data? > > I agree than OpenID is (quite) dead, but I rather prefer OpenID to use > user/pass. I have big hopes for Mozilla Persona, looking forward > Python infrastructure support :). > > PS: I use "http://www.jcea.es/"; as my OpenID identity, and I delegate > the actual service to "myOpenID". I can switch delegation trivially. > http://bugs.python.org/?@action=openid_login&provider=Google Eli ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Sep 5, 2013, at 2:25 PM, Oleg Broytman wrote: > On Thu, Sep 05, 2013 at 02:16:29PM -0400, Donald Stufft > wrote: >> >> On Sep 5, 2013, at 2:12 PM, Oleg Broytman wrote: >>> I used to use myOpenID and became my own provider using poit[1]. >>> These days I seldom use OpenID -- there are too few sites that allow >>> full-featured login with OpenID. The future lies in OAuth 2.0. >> >> The Auth in OAuth stands for Authorization not Authentication. > > There is no authorization without authentication, so OAuth certainly > performs authentication: http://oauth.net/core/1.0a/#anchor9 , > http://tools.ietf.org/html/rfc5849#section-3 They are separate topics and authorization does not need to imply authentication, it so happens that in many particular instances of OAuth you can estimate authentication. https://en.wikipedia.org/wiki/OAuth#OpenID_vs._pseudo-authentication_using_OAuth Persona is the logical successor to OpenID. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sep 05, 2013, at 07:31 PM, Jesus Cea wrote: >I just received an email from my OpenID provider, "myOpenID", saying >that they drop OpenID service next February. I wonder what other >OpenID providers are used by other python-dev fellows. > >What are you using?. bugs.python.org admins could share some data? Launchpad. It's not going anywhere. >I agree than OpenID is (quite) dead, but I rather prefer OpenID to use >user/pass. I have big hopes for Mozilla Persona, looking forward >Python infrastructure support :). We at the Mailman project like Persona a lot. It'll be the primary way people can log into Postorius (the new web ui). - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSKM3TAAoJEBJutWOnSwa/jP8QAJ4BkV8285TexZq+9GuTwzFf qx2OlUwtiv6lhDZq9uY0sXijyKl76N0/nTsSf5Fr8nDsn5KaETd14PFGfwbg6WVS jMZcKz+3j7eq6zq/Qm47qFbcBb2moyxptkE96BMCqEw+DCnPo87q8DXOb2W67ROI XDsRW2T/D8v5SvAqkmgOPlWsXWc1QzOpJCGkYcufzDeCjkFPXvck3mFI0TpizXnv 7L4IjrK9Qn6D1zNvKmovTkQOu3sk3C2FvPT2QG0b+DWkPtERE6o/xK2OTkhIzbBd /YfLEkb60tJYtwKqfHei+n4pVreExT0DtCDFHh5bYbdcD23VuHfDZtaHCDzYEhK9 rjuY2odydxD/xH9F21enHqYuU76TBr8ceodYsP2FNlqO5XeOJwgAXhWdpBYwN+SU G0B5k3wDb6VCDkqM1u7VGcA/yQLeGQ43s/klxxAxo08sA3url9HcIeuO5rnmnB5l lGIehq/SJPVQXQevEJvL8Atm7uLnsaWEJg34+T04MyR+TLeUcjKsNrUZBS8bGOZu agygKg3M/zi1k9LW/uxKR7IKLyBK+axYoEQS9yydqpgO1e8BQa6XlLQ89Sv9r38Y y1qTFmGdRRQSItrlS1urMQ9Q8m7pJBSyfBywlsck07hpXlZLRwRm2S3DnMBrF6It I7f28XXirrnBf/la/+6g =xqI7 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 05, 2013 at 07:31:59PM +0200, Jesus Cea wrote: > I just received an email from my OpenID provider, "myOpenID", saying > that they drop OpenID service next February. I wonder what other > OpenID providers are used by other python-dev fellows. > > What are you using?. bugs.python.org admins could share some data? > > I agree than OpenID is (quite) dead, but I rather prefer OpenID to use > user/pass. I have big hopes for Mozilla Persona, looking forward > Python infrastructure support :). > > PS: I use "http://www.jcea.es/"; as my OpenID identity, and I delegate > the actual service to "myOpenID". I can switch delegation trivially. I used to use myOpenID and became my own provider using poit[1]. These days I seldom use OpenID -- there are too few sites that allow full-featured login with OpenID. The future lies in OAuth 2.0. 1. http://yangman.ca/poit/ Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 05, 2013 at 02:16:29PM -0400, Donald Stufft wrote: > > On Sep 5, 2013, at 2:12 PM, Oleg Broytman wrote: > > I used to use myOpenID and became my own provider using poit[1]. > > These days I seldom use OpenID -- there are too few sites that allow > > full-featured login with OpenID. The future lies in OAuth 2.0. > > The Auth in OAuth stands for Authorization not Authentication. There is no authorization without authentication, so OAuth certainly performs authentication: http://oauth.net/core/1.0a/#anchor9 , http://tools.ietf.org/html/rfc5849#section-3 Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Sep 5, 2013, at 2:12 PM, Oleg Broytman wrote: > On Thu, Sep 05, 2013 at 07:31:59PM +0200, Jesus Cea wrote: >> I just received an email from my OpenID provider, "myOpenID", saying >> that they drop OpenID service next February. I wonder what other >> OpenID providers are used by other python-dev fellows. >> >> What are you using?. bugs.python.org admins could share some data? >> >> I agree than OpenID is (quite) dead, but I rather prefer OpenID to use >> user/pass. I have big hopes for Mozilla Persona, looking forward >> Python infrastructure support :). >> >> PS: I use "http://www.jcea.es/"; as my OpenID identity, and I delegate >> the actual service to "myOpenID". I can switch delegation trivially. > > I used to use myOpenID and became my own provider using poit[1]. > These days I seldom use OpenID -- there are too few sites that allow > full-featured login with OpenID. The future lies in OAuth 2.0. The Auth in OAuth stands for Authorization not Authentication. > > 1. http://yangman.ca/poit/ > > Oleg. > -- > Oleg Broytmanhttp://phdru.name/p...@phdru.name > Programmers don't die, they just GOSUB without RETURN. > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
