Changes between Initial Version and Version 1 of Ticket #23446, comment 1
- Timestamp:
- 02/12/2013 08:36:12 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #23446, comment 1
initial v1 1 Since you're going to the trouble of proposing changes in WordPress's API to support this useful screen-scraping, wouldn't it make more sense to support a method "wp _authenticate()" or similar that would explictly return a cookie suitable for session-scoped requests to the site as the logged-in user?1 Since you're going to the trouble of proposing changes in WordPress's API to support this useful screen-scraping, wouldn't it make more sense to support a method "wp.authenticate()" or similar that would explictly return a cookie suitable for session-scoped requests to the site as the logged-in user? 2 2 3 3 I can imagine push-back that the API shouldn't empower clients to access the whole site like this, but the fact is as Danilo notes you can automate this through screen-scraping, anway. If you are going to go the extra step of outright advertising the required APIs for accomplishing this, why not make the whole process more foolproof? 4 4 5 The added benefit of formalizing this is you would then also have a central point of authentication for this person, that the user could disable either through plugin or admin-panel options. In that scenario, if a client app attempts to wp _authenticate() and receives an error, they can pass it along to the user.5 The added benefit of formalizing this is you would then also have a central point of authentication for this person, that the user could disable either through plugin or admin-panel options. In that scenario, if a client app attempts to wp.authenticate() and receives an error, they can pass it along to the user. 6 6 7 7 I don't think concessions should be made to supporting full "browser-style" authentication unless you go all the way and make it foolproof and more administratable.