yii2 REST authentication keeps its authentication information - rest

Iam working on a REST module in Yii2. The client is able to authenticate on the server and is also able to get the requested response. I have seen, that the client authenticates one time to the system. It seems that the client stores its authentication information, because no further authentication for following requests is needed.
Of course, Iam interested that each REST request needs an authentication. I have seen, that there could be one way to do some fixed settings in the configuration of the app, which I would like to avoid.
I guess that the authentication information is stored in a cookie. I assume that the cookie is named'_csrf-frontend'. Now I try to remove this cookie within a controller function.
$cookies = \Yii::$app->response->cookies;
$cookies->remove('_csrf-frontend');
unset($cookies['_csrf-frontend']);
I've added additionaly recommended settings of Idgs answer, but still no luck. After a refresh of the page the authentication information must be kept, because still no authentication is necessary.
A look in the Headers shows:
Response Header:
Cache-Control no-store, no-cache, must-revalidate
Connection Keep-Alive
Content-Type application/json; charset=UTF-8
Date Thu, 29 Mar 2018 06:36:37 GMT
Expires Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive timeout=5, max=100
Pragma no-cache
Server Apache/2.4.18 (Ubuntu)
Set-Cookie _csrf-frontend=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; HttpOnly _identity-frontend=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; HttpOnly
Transfer-Encoding chunked
Request Header:
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language de,en-US;q=0.7,en;q=0.3
Authorization Basic ZG9yaXMua3JhdXNAdmVydHJlbmQuY29tOktyYXVzMTAwMA==
Connection keep-alive
Cookie eafab809c11b0a847c07e9c4f2b93936=uv3f1tof6la24616p7bkf59p55; advanced-frontend=mobbni6v6492kde73amtdvcqi3; _csrf-frontend=4d2ddb54290d2fa7fcc9c4a9900726b795e83aadc658fc0f50395bf7ded0c86aa%3A2%3A%7Bi%3A0%3Bs%3A14%3A%22_csrf-frontend%22%3Bi%3A1%3Bs%3A32%3A%22Oiy_JOiLMg_X0Hz666f0OWpG_r-jcvnO%22%3B%7D
DNT 1
Host localhost
Upgrade-Insecure-Requests 1
User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Only, if I remove all of the Browsers Chronik in Firefox, then a new authentication request is coming up.

It's probably not the CSRF feature that's setting the login cookie, see: rest-authentication docs, which tells you how to disable the login session.
Disable Sessions
If you don't want to use the recommended config settings:
'user' => [
'enableSession' => false,
'enableAutoLogin' => false,
You can set the values in your controller like:
public function init()
{
parent::init();
Yii::$app->user->enableSession = false;
Yii::$app->user->loginUrl = null;
}
Disable CSRF
If you also want to turn off CSRF (e.g., if you have any web form POSTS to your API), either update the request component in your web config like:
'components' => [
'request' => [
'enableCsrfValidation' => false,
or to turn CSRF off in your controller, use:
$this->enableCsrfValidation = false;
(Obviously you would want to implement your own CSRF protection as applicable if you do turn it off.)

Related

Twitter API 1.1 returns an Authentication Error (Error 32) when sending the INIT command to start the video upload process

I am trying to upload a video to Twitter using the chunked upload endpoint. For this I post to the endpoint '**https://upload.twitter.com/1.1/media/upload.json**' the 'INIT' command. n posting to the Twitter server I get the error below
{"errors":[{"code":32,"message":"Could not authenticate you."}]}
At first I had a doubt regarding the Oauth signature generation function. But I can post a tweet and upload a .png image to the https://upload.twitter.com/1.1/media/upload.json using the Oauth signature generated by this Oauth signature generation function
I could also post the 'INIT' command initiate the chunked upload of a video successfully using TWURL
I have pasted below the actual request and response which was captured using Fiddler
Request
POST https://upload.twitter.com/1.1/media/upload.json HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: upload.twitter.com
Authorization: OAuth oauth_consumer_key="", oauth_nonce="MDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMDAwMDAwMDAwMDAw", oauth_signature_method="HMAC-SHA1", oauth_signature="BtxgmRxA1bt5FI2Hu3qhhVIb5Eg%3D", oauth_timestamp="1607577817", oauth_token="****", oauth_version="1.0"
Content-Length: 357
Connection: Keep-Alive
command=INIT&media_category=tweetvideo&media_type=video%252Fmp4&oauth_consumer_key=******&oauth_nonce=MDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMDAwMDAwMDAwMDAw&oauth_signature=BtxgmRxA1bt5FI2Hu3qhhVIb5Eg%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1607577817&oauth_token=********&oauth_version=1.0
Response
HTTP/1.1 401 Authorization Required
cache-control: no-cache, no-store, max-age=0
content-length: 64
content-type: application/json; charset=utf-8
date: Thu, 10 Dec 2020 05:23:39 GMT
server: tsa_k
set-cookie: personalization_id="v1_jQ8zK7e0TgY2uCQKkiVOgA=="; Max-Age=63072000; Expires=Sat, 10 Dec 2022 05:23:39 GMT; Path=/; Domain=.twitter.com; Secure; SameSite=None
set-cookie: guest_id=v1%3A160757781933882195; Max-Age=63072000; Expires=Sat, 10 Dec 2022 05:23:39 GMT; Path=/; Domain=.twitter.com; Secure; SameSite=None
strict-transport-security: max-age=631138519
vary: Origin
x-connection-hash: 0e6ebd96e051b8f7a413fb79c51a8f42
x-frame-options: SAMEORIGIN
x-response-time: 182
x-tsa-request-body-time: 0
x-xss-protection: 1; mode=block
{"errors":[{"code":32,"message":"Could not authenticate you."}]}
i googled a lot for a solution to this issue but none of the solutions are working. I also read the relevant Twitter documentation many many times
Thanks in advance for any tips
Mathew
Finally found what was causing the error. While passing the URL to which data has to be posted to the function that I use to generate the Oauth signature I was passing 'https://upload.twitter.com/1.1//media/update.json.com' instead of 'https://upload.twitter.com/1.1/media/update.json.com'. One additional '/' character was the reason why the error was occurring.
Thanks and regards
Mathew

REST - How to use auth token in subsequent requests

I'm using a java application the provide a REST interface for mongodb database called "RESTHeart"
When I make a normal GET request.
http -a admin:temp http://172.18.18.122:8080/_logic/roles/admin
I get an auth token Auth-Token: 10dc2eeb-9624-47f2-a542-c97e0af82b23, how can I use it subsequent requests?
Here is the full response
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Location, ETag, Auth-Token, Auth-Token-Valid-Until, Auth-Token-Location, X-Powered-By
Auth-Token: 10dc2eeb-9624-47f2-a542-c97e0af82b23
Auth-Token-Location: /_authtokens/admin
Auth-Token-Valid-Until: 2016-04-25T14:37:22.290Z
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 109
Content-Type: application/hal+json
Date: Mon, 25 Apr 2016 14:22:22 GMT
X-Powered-By: restheart.org
{
"_links": {
"self": {
"href": "/_logic/roles/admin"
}
},
"authenticated": true,
"roles": [
"ADMIN"
]
}
I have tried the following:
http http://172.18.18.122:8080/_logic/roles/admin Auth-Token:'10dc2eeb-9624-47f2-a542-c97e0af82b23'
Response:
HTTP/1.1 403 Forbidden
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Location, ETag, Auth-Token, Auth-Token-Valid-Until, Auth-Token-Location, X-Powered-By
Connection: keep-alive
Content-Length: 0
Date: Mon, 25 Apr 2016 14:30:27 GMT
X-Powered-By: restheart.org
I'm not sure what I'm doing wrong here, any ideas?
with httpie you can simply do:
http -a <username>:<Auth-Token> GET http://172.18.18.122:8080/auth/users
I found the solution for this question, all what I needed was to pass authorization header along with 'username:password' encoded in base64 format
http GET http://172.18.18.122:8080/auth/users authorization:'Basic YWRtaW46dGVtcA=='
Clients authenticate passing credentials via the standard basic authentication, a standard method for an HTTP user agent to provide a username and password when making a request.
RESTHeart is stateless: there isn't any authentication session and credentials must be sent on every request.
Of course, it means you must secure your communications with HTTPS.
There's documentation on how the authentication process works in restheart at https://softinstigate.atlassian.net/wiki/x/JgDM

Microsoft Calendar REST API - Access to OData is disabled

I'm trying to access Microsoft's Outlook.com Calendar REST API. I got OAUTH2 authentication set up correctly and have a valid access token and refresh token available.
However, if I try to access the calendar list # https://outlook.office.com with my access token:
GET /api/v1.0/me/calendars HTTP/1.1
Accept: application/json; odata.metadata=none
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciO[...]
the service returns with an 403 Forbidden
HTTP/1.1 403 Forbidden
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8
Server: Microsoft-IIS/8.5
Set-Cookie: ClientId=OD6KHQBTKOKMLXUI8OJEG; expires=Wed, 21-Sep-2016 18:37:21 GMT; path=/; secure; HttpOnly
Set-Cookie: exchangecookie=8e4f582170cb445780c7148e9494b293; expires=Thu, 22-Sep-2016 18:37:23 GMT; path=/; HttpOnly
Set-Cookie: ClientId=OD6KHQBTKOKMLXUI8OJEG; expires=Wed, 21-Sep-2016 18:37:21 GMT; path=/; secure; HttpOnly
request-id: 7113f37d-69e0-4f8c-a264-9f3599d47899
X-CalculatedBETarget: CY1PR08MB1801.namprd08.prod.outlook.com
X-BackEndHttpStatus: 403
OData-Version: 4.0
X-AspNet-Version: 4.0.30319
X-DiagInfo: CY1PR08MB1801
X-BEServer: CY1PR08MB1801
X-Powered-By: ASP.NET
X-FEServer: AM3PR04CA0074
X-MSEdge-Ref: Ref A: D69A31E4FAA44258B0B8C351A71D2F9E Ref B: 0D3CA60C0976F50C452293F8CF403D8C Ref C: Tue Sep 22 11:37:23 2015 PST
Date: Tue, 22 Sep 2015 18:37:22 GMT
{"error":{"code":"ErrorAccessDenied","message":"Access to OData is disabled."}}
I played around with Outlook's OAuth Sandbox, where the same request returns a 200 OK with the correct data in the body. Strangely enough, they spot a nice little Show me the cURL! button in the sandbox, but this exact curl command will fail again with a 403 error in my terminal.
What am I missing?
I talked to a Microsoft techie. My problem was, that the REST API is not public (yet) and Microsoft has not yet enabled the API for standard Outlook.com accounts.
I requested an Outlook developer preview account with the REST API enabled by writing an email to outlookdev#microsoft.com
It took some time until I got a response from Microsoft, but using the developer account everything works now as expected.

Cookies going through moovweb project have their domains overwritten to "."

I have a project using the mixer "simple-mobile (1.0.183)". I a request returns a response with the Set-Cookie header, those cookies have the domain set to just "."
Here's an example response header from a curl:
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html; charset=UTF-8
Content-Length: 23
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Set-Cookie: ASP.NET_SessionId=xu1qyg45ghzqveeuwa1ix1aa; path=/; HttpOnly; domain=.
Set-Cookie: ec_session=511840684.20480.0000; path=/; domain=.
Vary: Accept-Encoding
Connection: keep-alive
As you can see, the domain section of the cookie is set to just "." I'm not really messing with cookies anywhere in my tritium, and I don't use any of the cookie helper functions. I've had other moovweb projects set the domain correctly (in this case, it would be ".example.com").
Anyone know what might be going on with my cookies?

Application Permissions Request Endlessly Redirects with IE

This code works great for all browsers except Internet Explorer.
Basically when the redirect is sent to IE it just request the exact same URL again from my server, it just ignores the redirect.
Using the 3.1.1 code from Naitik Shah
Here's the code:
// $g_facebook is declared earlier and given app id and secret
$par[ 'scope' ] = array( 'publish_stream' , // publish to the user's stream
'offline_access' , // access these functions when the user is offline
// 'user_status' , // get the user's latest status
// 'read_stream' , // read the user's stream
'email' , // provides the user's email address
'user_groups' , // provides the user's groups
// 'sms' , // send and receive txt w/ user
'publish_actions', // publish scores and achievements
);
header( 'Location: ' . $g_facebook->getLoginUrl( $par ) );
exit( );
Here's what happens on the wire (picked it up with tcpdump):
GET /fork HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C)
Accept-Encoding: gzip, deflate
Host: fbar.toolsteam.com
Connection: Keep-Alive
Cookie: PHPSESSID=7f32d7e4acd63696bd8d0998913f608c; PHPSESSID=e30076106b21e40142397219283fd55f
HTTP/1.0 302 Moved Temporarily
Date: Mon, 07 May 2012 07:36:12 GMT
Server: Apache
X-Powered-By: PHP/5.3.10
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=a9f17a1119dc262bef693d2d39a15317; expires=Tue, 07-May-2013 07:36:12 GMT; path=/
Location: http://www.facebook.com/dialog/oauth?client_id=336243633108439&redirect_uri=http%3A%2F%2Ffbar.toolsteam.com%2Ffork&state=b52dd5dd08e0058e28ae8734f269cd77&scope=publish_stream%2Coffline_access%2Cemail%2Cuser_groups%2Cpublish_actions
Content-Length: 0
Content-Type: text/html
X-Cache: MISS from base
X-Cache-Lookup: MISS from base:3128
Via: 1.1 base:3128 (squid/2.7.STABLE9)
Connection: keep-alive
When IE sees the 302 it just sends the original request again and again. It never follows the redirect to facebook.
As said before, Chrome and Firefox have no problems.
Ideas?
The answer was in the request headers:
Cookie: PHPSESSID=7f32d7e4acd63696bd8d0998913f608c; PHPSESSID=e30076106b21e40142397219283fd55f
There are two servers involved in this facebook auth, one is the originating website, the second is an intermediate server that negotiates the facebook permissions. The facebook server is a sub-domain of the primary site.
Turns out both of them were starting php sessions. The facebook server's cookie was at the sub-domain scope, the primary site's cookie was at the top-domain scope.
For whatever reason IE couldn't handle sending the same cookie twice on a request to the facebook server - it handled the transaction just fine but for whatever reason would just re-request the same URL and ignore the 302 redirect. IE is like that.
I switched the session variable name on the facebook server and the problem disappeared.