Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

block all robots in robots.txt #1

Merged
merged 1 commit into from Apr 8, 2017
Merged

block all robots in robots.txt #1

merged 1 commit into from Apr 8, 2017

Conversation

@nolanlawson
Copy link
Member

@nolanlawson nolanlawson commented Apr 8, 2017

We can change this later, e.g. to configure it on a per-user basis, but defaulting to most-private seems best.

@nolanlawson
Copy link
Member Author

@nolanlawson nolanlawson commented Apr 8, 2017

Merging, just opening the PR for transparency

Loading

@TekBear
Copy link

@TekBear TekBear commented Apr 13, 2017

I think you should not block archive.org crawler - recording history is important

Loading

nolanlawson pushed a commit that referenced this issue Apr 14, 2017
@nolanlawson
Copy link
Member Author

@nolanlawson nolanlawson commented Apr 28, 2017

@TekBear I'd need to ask what the community thinks. If they're okay with it, then I'm okay with it. :)

Loading

@nemobis
Copy link

@nemobis nemobis commented Aug 31, 2018

Did you mean to block the Internet Archive Wayback machine as well?

Loading

@nolanlawson
Copy link
Member Author

@nolanlawson nolanlawson commented Oct 29, 2018

Yes. This is a block of everything.

Loading

nolanlawson pushed a commit that referenced this issue Feb 26, 2020
…stodon#12390)

When authenticating via OAuth, the resource owner password grant
strategy is allowed by Mastodon, but (without this PR), it does not
attempt to authenticate against LDAP or PAM. As a result, LDAP or PAM
authenticated users cannot sign in to Mastodon with their
email/password credentials via OAuth (for instance, for native/mobile
app users).

This PR fleshes out the authentication strategy supplied to doorkeeper
in its initializer by looking up the user with LDAP and/or PAM when
devise is configured to use LDAP/PAM backends. It attempts to follow the
same logic as the Auth::SessionsController for handling email/password
credentials.

Note #1: Since this pull request affects an initializer, it's unclear
how to add test automation.

Note #2: The PAM authentication path has not been manually tested. It
was added for completeness sake, and it is hoped that it can be manually
tested before merging.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants