System Info:
Ubuntu 18.04.1
Apache 2.4.29
PHP 7.2.19
Server always reports that a csrf token on a login form is invalid. I have followed the symfony guide a couple Symfony guides https://symfony.com/doc/current/security/csrf.html#csrf-protection-in-login-forms and https://symfony.com/doc/current/security/form_login_setup.html
I have searched all over and cannot seem to find things to look at. I have check all sorts of file permissions and the only thing I can think of is to use php version 7.1 where i know it works.
Here you can see the token generated on the /login and
And the same data in authenticator
PHP did not have write access to its session storage.
Related
I don't think this issue is specific to PyDrive, but rather Google OAuth. However, some of the solutions I've seen on stackoverflow don't seem to be transferable over to my PyDrive application, which is just a python script to upload files programmatically to a shared drive. It worked fine 2 months ago but I tried to rerun it today and it's not working. Here is the error I'm getting:
Authorisation Error
Error 400: invalid_request
You can't sign in to this app because it doesn't comply with Google's OAuth 2.0 policy for keeping apps secure.
You can let the app developer know that this app doesn't comply with one or more Google validation rules.
Request Details
The content in this section has been provided by the app developer. This content has not been reviewed or verified by Google.
If you’re the app developer, make sure that these request details comply with Google policies.
redirect_uri: urn:ietf:wg:oauth:2.0:oob
I am using a web application OAuth 2.0 Client ID creds on GCP. All secrets are stored in a local client_secrets.json file.
I run my script, it sends a message to the console that says
Go to the following link in your browser:
https://accounts.google.com/o/oauth2/auth?client_id=blahblahblah.apps.googleusercontent.com&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive&access_type=offline&response_type=code
Enter verification code:
How it used to work: After I click the link above, it returns a code I paste into the console and then its authenticated. FYI: I plan on running this 24/7 on a remote server.
Now: I click the link above and get the error I posted above. I've tried to change the redirect uri to 127.0.0.1 and it does allow me to auth, then I get a code in my URL, but once I copy that and paste it into the console, I get more errors.
Anyone know the solution for this?
I'm trying to get omniauth-saml configured, but I'm not entirely sure what I need to put in app_id and app_secret for this configuration.
I'm using this gem: https://github.com/PracticallyGreen/omniauth-saml
If I leave those fields blank, of course I get:
Received wrong number of arguments. [nil, nil]
The documentation within the gitlab.yml file links to more documentation about gitlab and omniauth, but that document no longer exists (redirects to old README).
Any assistance would be appreciated, thanks!
https://github.com/gitlabhq/gitlab-public-wiki/wiki/Working-Custom-Omniauth-Provider-Configurations#working-cas-configuration
The working CAS configuration shows you how you skip using the standard configuration and just pass the options directly to the provider using devise.rb. That's how I would configure omniauth-saml as well.
I was able to get SAML working with Gitlab 6.2.4, but it is not the most elegant solution. I am using Okta as the IdP, but I believe the configuration is sufficiently generic and could be applied to any SAML IdP.
Added omniauth-saml to the Gemfile and ran bundle
bundle install --without development test postgres --path vendor/bundle --no-deployment
Created GITLAB/config/initializers/omniauth.rb
Devise.setup do |config|
config.omniauth :saml,
idp_cert_fingerprint: "your IdP certificate fingerprint",
idp_sso_target_url: "your IdP SAML end point"
end
Modified GITLAB/app/controllers/omniauth_callbacks_controller.rb (added this following the definition for ldap)
def saml
handle_omniauth
end
I had to manually add the callback for SAML as I was getting the same error as the original poster when I tried to properly define SAML as a provider in gitlab.yml. This is the only way I could get Gitlab to start and authenticate via SAML. This feels very hacky, so there is probably a more elegant way to implement this; however, I could not find an example anywhere.
https://github.com/gitlabhq/gitlab-public-wiki/wiki/Custom-omniauth-provider-configurations#working-saml-configuration
I managed to get it to work, so I documented the procedure on the GitLab wiki.
EDIT: It seems like SAML is now supported officially. No Single Logout yet, though… This seems to be an omniauth limitation.
I am writing an application using data from Redmine. I use its REST API to get data.
It works fine with projects or issues, but when I try to access users' data I just can't because it asks for credentials in the browser, and it responds with HTTP error code 401 to my HTTP request from my program.
How do I find a solution to this problem?
Environment:
Redmine version 2.1.2.stable
Ruby version 1.8.7 (i386-mingw32)
Ruby on Rails version 3.2.8
Environment production
Database adapter MySQL
I've figured out. It is described very detailed on the Redmine wiki.
There are a couple of options to authenticate yourself.
The easiest is to include a plus field in your query, named key. You must include your user's REST API key there in each query.
Like:
localhost/redmine/users.xml?key=eaksdnynkdnasdfnaskdsar
It is very interesting because in earlier versions (2.1.0) it asks for the authentication for each XML file. But in my version, 2.1.3, it doesn't ask, only if I request users data.
I have foursquare app that gets authorization from Foursquare. It used to work but after the server upgrade it stopped working as timeout after 30 seconds.
We were using Apache 2.2.6 and PHP 5.2.12 and upgraded it to Apache 2.2.22 & PHP 5.3.17. We updated php codes according to 5.3.17 which are mostly db stuff. Anyhow our Foursquare server side app isn’t not working since. We tried it on other old server with old setup, then it works.
Specifically, access token is not returned on the request for authorization on our app when a user try to use it.
We are using this format below for making the request.
https://foursquare.com/oauth2/access_token
?client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET
&grant_type=authorization_code
&redirect_uri=YOUR_REGISTERED_REDIRECT_URI
&code=CODE
All of values are filled accordingly.
Any hint or clue would be helpful!
You can try requesting the URL from your browser, and seeing the response generated. This should give you more information about the error occurring.
In your browser, you can imitate a user and follow the flow that they would use to authorize your app. Then, you can take the code parameter from the url, and visit the access_token link in your browser to see the response.
We are currently facing a production issue on Websphere 7 with respect to richfaces fileupload component. The problem description is that immediately after the file for upload is browsed and selected using this component, the basic authentication dialogbox appears asking for user credentials.
Following are the frameworks we are using in our project:
JSF 1.2 & Richfaces 3.3.3
Spring Framework 3.x
Spring Webflow 2.1
Spring Security 3.x (only basic authentication using login dialogbox)
The user is authenticated once when he wants to access the application at the beginning using basic authentication. All screens that dont use fileupload component are working fine. But if we use fileupload component, as I mentioned above, the file selection (even from local machine path) triggers the basic authentication dialogbox again. The strange thing is that this behaviour does not occur on our Dev Environment which uses Tomcat 6. On Tomcat, the fileupload is not triggering any user login and upload is working fine.
This problem is occuring only when the app. is deployed on Websphere 7. Can anybody please tell whether Websphere requires any additional configuration for accessing Files through this component ?
We have spent a lot of time investigating this problem without any meaningful results. As this is a production issue for us now, it is very critical and needs to be resolved at the earliest.
So please help in this regard. Thanks in advance.
I don't know the File Upload component, and the answer may well lie in the detail of how that works, but in general WebSphere will challenge if an HTTP request arrives for a protected resource and the request does not contain a valid LTPA cookie. The cookie is normally sent by the browser on each request when authentication has happended once, BUT it will only do so if it believes that the cookie is related to a given domain. So if the main part of your website were served from, say,
htpp://my.own.org.com/mysite
and the file upload were related to a subtly different host
http://my.other/filesite
Then the cookie would not be sent, and a challenge would result.
My approach to diagnosing this would be get some kind of traffic sniffer. See exactly what is flowing and the addresses being used. I'm predicting that you will see the LTPA cookie in the usual case and not in the upload case. Then it's a matter of figuring out "why".