??xml version="1.0" encoding="utf-8" standalone="yes"?>国产成人精品最新,亚洲在线视频网站,亚洲国产成人久久http://www.aygfsteel.com/bluepluto/category/4222.htmlzh-cnTue, 29 Apr 2014 04:28:51 GMTTue, 29 Apr 2014 04:28:51 GMT60OAuth 2.0 Noteshttp://www.aygfsteel.com/bluepluto/archive/2014/04/08/412118.html一直在努力 !一直在努力 !Tue, 08 Apr 2014 15:43:00 GMThttp://www.aygfsteel.com/bluepluto/archive/2014/04/08/412118.htmlhttp://www.aygfsteel.com/bluepluto/comments/412118.htmlhttp://www.aygfsteel.com/bluepluto/archive/2014/04/08/412118.html#Feedback0http://www.aygfsteel.com/bluepluto/comments/commentRss/412118.htmlhttp://www.aygfsteel.com/bluepluto/services/trackbacks/412118.html
[1] http://blog.gopivotal.com/cloud-foundry-pivotal/products/open-standards-in-cloud-foundry-identity-services
[2] http://tutorials.jenkov.com/oauth2/index.html

Summary
Authorization Code 方式是最完整? Client Application 会被重定向到 OAuth Server dq同意授? 之后再返回业务系l? 业务pȝ通过 Authorization Code ?OAuth Server 处获取访问最l?Resource Server ?Access Token
Implicit ?Authorization Code 大体cM, 只是了?Auhtorization Code 获取 AccessToken 的步?br />Resource Owner 方式是客L序知道用户名和密? 认证时连同自w的 Client ID 和密码一起发送到 OAuth Server, 比如 CF Java 客户端就是用这U方?br />Client Credentials ?Client Application 本nqg Resource Owner


1. OAuth Client 首先需要在 OAuth Server 注册, 需要提供一?Redirect URL, q从 OAuth Server 获取 Client ID ?Client 密码
2. 基本程
    a. 用户讉K客户端应用程?br />    b. 客户端应用重定向?OAuth Server
    c. 用户输入用户名和密码d, OAuth Server 执行?Authentication ? 会提C用h否允许访问数?br />    d. OAuth Server 使用注册的重定向 URL, 用户再次被定向到客户端应用程? 此时 URL 会包?Authentication Code
    e. 客户端应用程序接收到h? 使用 Authentication Code/Client ID/Client Password 讉K OAuth Server 获取 Access Token
    
3. OAuth 中四个角?br />    a. Resource Owner : One person or one application
    b. Resource Server
    c. Client Application
    d. Authorization Server
    * b ?d 可以在一? OAuth 规范未作详细规定, 其之间如何交互也无规?br />    
4. OAuth Client cd
    a. Confidential
    b. Public
    OAuth 客户端需要持?Client ID ?Client Password, 两种cd的区别在? W三Ҏ否可以通过某种方式获取该信?

5. Client Profile
    a. Web Application 指运行在 Web 服务器上?Web 应用, 实际场景? q可能包含客L览?nbsp;      
    b. User Agent 比如q行在浏览器中的 JavaScript 应用
    c. Native 比如桌面应用或者移动手机应?br />    
6. OAuth 2.0 Authorization
    a. 注册?OAuth 服务? 一般执行一? Client Application 会获取分配的 Client ID ?Client Password. 注册q程? Client Application 需要提?Redirect URI
    This redirect URI is used when a resource owner grants authorization to the client application. When a resource owner has successfully authorized the client application via the authorization server, the resource owner is redirected back to the client application, to the redirect URI.
    b. 无论何时 Client Application h Resource Server 上的资源? Client Application 都需要到 OAuth Server 处?ID ?密码执行认证
    
7. Authorization Grant ?Resource Owner 授予 Client Application. OAuth 2.0 定义了如何类?:
    a. Authorization Code
    b. Implicit
    c. Resource Owner Password Credentials
    d. Client Credentials
    
8. Authorization Code
    a. ?Client Application 重定向到 OAuth Server ? Client ID 也会被传递过? q样 Authorization Server 可以知道哪个应用 (Client Application) 试图讉K受保护资?br />    b. 当用h功登录ƈ授权讉K? OAuth Server 会?Client Application 注册时提供的 Redirect URI, 同时包含 Authentication Code.
    c. Client Application 使用 Authentication Code, Client ID ?Client Password 直接讉K Authorization Server, q过?Access Token. Access Token 代表 Client Application 通过认证和授权访问保护资? (The access token serves as both authentication of the client, and authorization to access the resources. )
    
9. Implicit ?Authentication Code 工作方式cM, 区别在于重定向时, Access Token 被包含在?
    a. An implicit authorization grant is similar to an authorization code grant, except the access token is returned to the client application already after the user has finished the authorization. The access token is thus returned when the user agent is redirected to the redirect URI.
    b. This of course means that the access token is accessible in the user agent, or native application participating in the implicit authorization grant. The access token is not stored securely on a web server.
    c. Furthermore, the client application can only send its client ID to the authorization server. If the client were to send its client secret too, the client secret would have to be stored in the user agent or native application too. That would make it vulnerable to hacking.
    d. Implicit authorization grant is mostly used in a user agent or native client application. The user agent or native application would receive the access token from the authorization server.
    
10. Resource Owner Password Credentials {h? 用户 (Resource Owner) 把用户名密码告诉 Client Application, 然后 Client Application 直接使用用户名和密码讉K Resource Server
     a. The resource owner password credentials authorization grant method works by giving the client application access to the resource owners credentials. For instance, a user could type his Twitter user name and password (credentials) into the client application. The client application could then use the user name and password to access resources in Twitter.
     b. Using the resource owner password credentials requires a lot of trust in the client application. You do not want to type your credentials into an application you suspect might abuse it.
     c. The resource owner password credentials would normally be used by user agent client applications, or native client applications.

11. Client Credentials 使用 Client Application 需要调?Resource Server 提供的一些功? 但这些功能不和Q?Resource Owner 相关
      Client credential authorization is for the situations where the client application needs to access resources or call functions in the resource server, which are not related to a specific resource owner (e.g. user). For instance, obtaining a list of venues from Foursquare. This does not necessary have anything to do with a specific Foursquare user.
      
12. OAuth 2.0 Endpoints
    a. Authorization Endpoint
        The authorization endpoint is the endpoint on the authorization server where the resource owner logs in, and grants authorization to the client application.
    b. Token Endpoint
        The token endpoint is the endpoint on the authorization server where the client application exchanges the authorization code, client ID and client secret, for an access token.
    c. Redirection Endpoint
         The redirect endpoint is the endpoint in the client application where the resource owner is redirected to, after having granted authorization at the authorization endpoint.
    
    a ?b 位于 Authorization Server ? c 位于客户端应用程序上
    
13. Authorization Code Grant Requests/Responses
    a. Authorization Request
        a1. response_type     Required. Must be set to code
        a2. client_id     Required. The client identifier as assigned by the authorization server, when the client was registered.
        a3. redirect_uri     Optional. The redirect URI registered by the client.
        a4. scope     Optional. The possible scope of the request.
        a5. state     Optional (recommended). Any client state that needs to be passed on to the client request URI.
    b. Authorization Response
         The authorization response contains the authorization code needed to obtain an access token. Here are the parameters included in the response:
         b1. code     Required. The authorization code.
         b2. state     Required, if present in request. The same value as sent by the client in the state parameter, if any.
    c. Authorization Error Response
          If an error occurs during authorization, two situations can occur.
          The first is, that the client is not authenticated or recognized. For instance, a wrong redirect URI was sent in the request. In that case the authorization server must not redirect the resource owner to the redirect URI. Instead it should inform the resource owner of the error.
          The second situation is that client is authenticated correctly, but that something else failed. In that case the following error response is sent to the client, included in the redirect URI:
          c1. error     Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning.
          c2. error_description     Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user.
          c3. error_uri     Optional. A URI pointing to a human-readable web page with information about the error.
          c4. state     Required, if present in authorization request. The same value as sent in the state parameter in the request.         
    d. Token Request
         Once an authorization code is obtained, the client can use that code to obtain an access token. Here is the access token request parameters:
         d1. grant_type     Required. Must be set to authorization_code .
         d2. code     Required. The authorization code received by the authorization server.
         d3. redirect_uri     Required, if the request URI was included in the authorization request. Must be identical then.        
    e. Token Response
          The response to the access token request is a JSON string containing the access token plus some more information:

            { "access_token"  : "...",
              "token_type"    : "...",
              "expires_in"    : "...",
              "refresh_token" : "...",
            }

        e1. The access_token property is the access token as assigned by the authorization server.
        e2. The token_type property is a type of token assigned by the authorization server.
        e3. The expires_in property is a number of seconds after which the access token expires, and is no longer valid. Expiration of access tokens is optional.
        e4. The refresh_token property contains a refresh token in case the access token can expire. The refresh token is used to obtain a new access token once the one returned in this response is no longer valid.  
        
14. Implicit Grant Request
     a. The implicit grant request contains the following parameters:
        a1. response_type     Required. Must be set to token .
        a2. client_id     Required. The client identifier as assigned by the authorization server, when the client was registered.
        a3. redirect_uri     Optional. The redirect URI registered by the client.
        a4. scope     Optional. The possible scope of the request.
        a5. state     Optional (recommended). Any client state that needs to be passed on to the client request URI.

     b.Implicit Grant Response
        The implicit grant response contains the following parameters. Note, that the implicit grant response is not JSON.
        b1. access_token     Required. The access token assigned by the authorization server.
        b2. token_type     Required. The type of the token
        b3. expires_in     Recommended. A number of seconds after which the access token expires.
        b4. scope     Optional. The scope of the access token.
        b5. state     Required, if present in the autorization request. Must be same value as state parameter in request.

    c. Implicit Grant Error Response

        If an error occurs during authorization, two situations can occur.
        
        The first is, that the client is not authenticated or recognized. For instance, a wrong redirect URI was sent in the request. In that case the authorization server must not redirect the resource owner to the redirect URI. Instead it should inform the resource owner of the error.

        The second situation is that client is okay, but that something else happened. In that case the following error response is sent to the client, included in the redirect URI:
        c1. error     Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning.
        c2. error_description     Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user.
        c3. error_uri     Optional. A URI pointing to a human-readable web page with information about the error.
        c4. state     Required, if present in authorization request. The same value as sent in the state parameter in the request.

15. Credentials Grant - Requests and Response
    a. Resource Owner Password Credentials Grant Request
        The request contains the following parameters:
        a1. grant_type     Required. Must be set to password
        a2. username     Required. The username of the resource owner, UTF-8 encoded.
        a3. password     Required. The password of the resource owner, UTF-8 encoded.
        a4. scope     Optional. The scope of the authorization.

    b. Resource Owner Password Credentials Grant Response
        The response is a JSON structure containing the access token. The JSON structure looks like this:

        { "access_token"  : "...",
          "token_type"    : "...",
          "expires_in"    : "...",
          "refresh_token" : "...",
        }

        b1. The access_token property is the access token as assigned by the authorization server.
        b2. The token_type property is a type of token assigned by the authorization server.
        b3. The expires_in property is a number of seconds after which the access token expires, and is no longer valid. Expiration of access tokens is optional.
        b4. The refresh_token property contains a refresh token in case the access token can expire. The refresh token is used to obtain a new access token once the one returned in this response is no longer valid.

16. Client Credentials Grant - Requests and Response
     a. The client credentials grant request contains the following parameters:
        a1. grant_type     Required. Must be set to client_credentials .
        a2. scope     Optional. The scope of the authorization.
        
    b. Client Credentials Grant Response
        The client credentials response contains the following parameters:

        { "access_token"  : "...",
          "token_type"    : "...",
          "expires_in"    : "...",
        }

        b1. The access_token property is the access token as assigned by the authorization server.
        b2. The token_type property is a type of token assigned by the authorization server.
        b3. The expires_in property is a number of seconds after which the access token expires, and is no longer valid. Expiration of access tokens is optional.

        A refresh token should not be included for this type of authorization request.        


]]>
(你的灯还亮着?q个问题是什? http://www.aygfsteel.com/bluepluto/archive/2005/10/27/17091.html一直在努力 !一直在努力 !Thu, 27 Oct 2005 11:16:00 GMThttp://www.aygfsteel.com/bluepluto/archive/2005/10/27/17091.htmlhttp://www.aygfsteel.com/bluepluto/comments/17091.htmlhttp://www.aygfsteel.com/bluepluto/archive/2005/10/27/17091.html#Feedback0http://www.aygfsteel.com/bluepluto/comments/commentRss/17091.htmlhttp://www.aygfsteel.com/bluepluto/services/trackbacks/17091.html    问题定义斚w学到?
       a.不要把他们的解决Ҏ误认为是问题的定?BR>       b.如果你太L地解决了他们的问题,他们永远都不会相信你真的解决了他们的问题
       c.你永q都不能肯定你已l有了一个正的定义Q即使在问题已经解决之后?BR>       d.你永q也不能肯定你有了一个正的定义Q但是永q不要放弃寻求它的努?BR>

]]>
温伯?lt;<你的灯亮着?>>(W一?问题的定? http://www.aygfsteel.com/bluepluto/archive/2005/10/27/17090.html一直在努力 !一直在努力 !Thu, 27 Oct 2005 11:15:00 GMThttp://www.aygfsteel.com/bluepluto/archive/2005/10/27/17090.htmlhttp://www.aygfsteel.com/bluepluto/comments/17090.htmlhttp://www.aygfsteel.com/bluepluto/archive/2005/10/27/17090.html#Feedback0http://www.aygfsteel.com/bluepluto/comments/commentRss/17090.htmlhttp://www.aygfsteel.com/bluepluto/services/trackbacks/17090.html        U约市金融区的心脏地带矗立着一座闪亮耀眼的73 层大|q就是被人称为徏{学C的雷龙塔。然而,遗憾的是Q尽雷龙塔q没有被完全住满Q房客们已经发现大楼的电梯不够用。甚至于有一些房客放来,如果甉|服务q不能很快得到改善的话,他们׃搬出大楼?BR>下面列出了大楼的一些事实:
1Q?U赁大楼的大部分办公室在工作日的早上9 点到下午5 点之间办公?BR>2Q?几乎所有用大楼的Z都与金融界有着某种方式的联pR?BR>3Q?所有住h较均匀地分布在大楼?3 层,甉|交通也一栗?BR>4Q?房东Z把剩余房间租出去Q已l在q告上做了大量的投资?BR>5Q?在金融区q个闭的小圈子里,所有不好的消息传播得像闪电一样快
?问题的解?BR>        1)    定问题的拥有?不同的拥有者会有一pd对应的解x?BR>               a.甉|使用?BR>                  eg.修理甉|,限制q入大楼的h?.....;
               b.大楼理?BR>                  eg.增加房租Q只需要更的房客可以支付抵Dƾ(建造大楼时所支出的),设法说服客户Q告诉他们正因ؓ大楼是一个极好极方便的工作地点,所以才会有大楼目前的电梯状?..
      2)     寚w题进行调?房客希望快走完大门与办公室之间的距?l验告诉我们,既然甉|无法提?距离无法~短,可以让他在走q段路时'忙碌'h,于是在走廊里立v镜子,q样许多Z停下来看看自׃天帅不帅,q样甉|׃会挤......后又发现部分员工爱在镜子上涂?D镜子不匝?既然q样,我给你笔,让所有h都能展示自己的才?同样又达C上述目的......

     正如序言中所?问题是期望与体验之间的差?差别出现?也就是问题被提出;
     a.最古老的Ҏ:我不?我没看到,我当他不存在,q个{略有时会有?BR>     b.立即针对差别提出解决Ҏ
     c.认问题的对?定义问题的本?
        一ơ失败的问题解决案例:
        我在LY目中做|上采购?客户针对意向表列表提?nbsp; :  我需要在q添加一个按钮时,我想通过点击他看到历史信?此时客已h出的解决Ҏ,?FONT color=#0000ff>与客戯论前我觉得问题是客户无法看到历史信息,或者说他期望对数据q行{?当然也许q也不是最l的问题所?但是我所能看到最q的^_^.׃pȝ设计上的原因,我了解了一?看似单的d一个按?需要改动的东西比较?M?{略一我不?g不行,客户因ؓ一些前期的原因,寚w目的满意E度不高,现在首要解决的是提高客户好感?既然要关注这个问?首先要摆Z个积极的姿?我和他说问题已放入问题列?且标注ؓhigh,q样l他一个印?问题已经得到x,他的意见得到了应有的重视(?,他是个LT,要是个MM那多?哈哈);我之后和他讨?/FONT>q个问题,他说为啥要添q个按钮?原因是想让操作h员关注当前正在维护的记录,剔除历史记录有利于聚焦工作重?事实上我q没有接触到最l用?所以我也无从得知他们是否有q个需?,我明白了,问题q一步显?是因为用h有办法区分当前记录的状?我当时晕了n?/FONT>),针对pȝ的实?现在已有一个状态列,如果我按照状态排?把当前未通过审核的意向表记录昄在前?g也能解决问题,我想提出q个解决Ҏ,我觉得挺完美,既解决了他的问题又解决了我实现难的问?不过.....他说q样的话有可能有一|C?0条记录中,前九条是未通过审核?最后一条是通过审核?觉得q是不爽,q和我说:你能解决?不能解决q?搞得我很没面?l局是在系l中写了一?诡异'的代?实现了该要求.
       之后一直在?撇除pȝ设计的缺陷外,Z么没能双赢的解决q个问题,象书中那h创造?l论?nbsp;                                     


                                                         我还很弱,q得l箋看这本书,^_^!

]]>
温伯?lt;<你的灯亮着?>>(章柏q的序言) http://www.aygfsteel.com/bluepluto/archive/2005/10/27/17089.html一直在努力 !一直在努力 !Thu, 27 Oct 2005 11:12:00 GMThttp://www.aygfsteel.com/bluepluto/archive/2005/10/27/17089.htmlhttp://www.aygfsteel.com/bluepluto/comments/17089.htmlhttp://www.aygfsteel.com/bluepluto/archive/2005/10/27/17089.html#Feedback0http://www.aygfsteel.com/bluepluto/comments/commentRss/17089.htmlhttp://www.aygfsteel.com/bluepluto/services/trackbacks/17089.html    我的理解是遇到问题要多站在别人的角度?同时要认识到自己与别人所处的位置的不?BR>2.解决问题的基本步?
   a.抓住问题的根?eg.客户提出某个变更?首先惛_的是他ؓ什么会提出变更,再根据这个原因与之商定解x?BR>   b.站在各个角度看待问题,方能知道问题的根?即扑ֈ解决Ҏ?仍需要对其不断审?保持警惕?BR>   c.区分问题的定义和解决Ҏ;eg.客户提出的往往是解x案而不是导致的Ҏ
   d.永远不要肯定自己已经解决问题?即everything goes well!(^_^,q不是折腾自己吗)
3.问题的定?问题其实是你的期望和你的感受之间的差别Q而且不管看上d何,Z很少知道他们要什?.直到..你给了他们所需要的东西.

]]>
վ֩ģ壺 | ɳ| ̨ǰ| ΢ɽ| ƽ| е| ˮ| ƽ| Ʊ| | Դ| | ͷ| ɽ| | ̨| ˹| °Ͷ| | | ʮ| | Ԫ| żҿ| | ͭϿ| | ϲ| | | ۽| | | ĩ| Ϻ| | | | Ž| ɽ| ϳ|