Develop Reference

Login Email with Google to Specific Domain Name

I am not able to find any documentation on how to restrict the login to my web application to only accept authentication requests from users with an email on a specific domain name or set of domain names. I would like to block as opposed to blacklist.
Does anyone have any document or template which how to achieve using jsp,angularjs,javascript, documentation on the officially accepted method of doing so, or an easy, secure work around?
For the record, I do not know any info about the user until they attempt to log in through Google's OAuth authentication. All I receive back is the basic user info and email.

You can use method of string class String. contain("#yourdomain") it will return boolean value true or false
It will go like..
if(request.getParameter("email").contains("#yourDomainName"))
Do something;

Is it possible to post to chat.postMessage as any user in a Slack team?

I'm building a Slack integration that is intended to modify some text and then post it to a Slack channel as though the user who triggered the command had said it.
e.g. /makeFace disapproval
#Ben 3:45pm
ಠ_ಠ
I ask for the client permission scope, which adds the chat:write:user permission. But when I hit the chat.postMessage endpoint, it only seems to allow you to post as the user who added the integration because the token it returns seems to be individuated for that user.
I know that giphy, for instance, sends its gif messages as though you are the originator, but I can't find out how they manage it. Is there any documentation for sending messages as other members of the team?

There are 2 ways to achieve this:
A. Overwriting username and icon
When you send a message with chat.postMessage it is possible to set a user name with the property username. The message will then appear as being send by that user (same for icon with icon_url).
However, this is not meant to impersonate real users, so even if you use the same username and icon as the real user the message will have the app tag, so that they can be distinguished from a real user.
Here is an example how it looks like (from a gamer Slack about flying and killing space ships):
But depending on what your requirements are that might work for you.
If you want to use it make sure to also set the as_user property to false (yes, really) and it will not work with a bot token, only with a user token.
See here for more details on how it works.
This also works for the legacy version of Incoming Webhooks, not with the current version of incoming webhooks though. (You can still get the legacy version, see this answer)
B. Having the user's token
Another approach is to always use the token from the respective user for sending the message. In combination with as_user = true messages sent by your app will look exactly as if they would come from the respective user (no APP tag).
To make that happen your app would need to collect tokens from all users on your workspace and store them for later use. This can be done by asking every user to install your app (called adding a "configuration") through the Oauth process (same you use to install your app to a workspace), which allows your app to collect and store those tokens for later use.

Update: This doesn't work. It impersonates the user who installed the app, so it merely seems to work... until another user tries to use it (and they end up impersonating you).
Go to your App's management page. Select "OAuth & Permissions".
Add the chat.write OAuth Scope to your app as a User Token Scope, not a Bot Token scope.
Take note of your User OAuth Token at the top of this page (not your But User OAuth Token).
Call chat.postMessage with
username = user id of the user you'd like to post on behalf of
token = the token from step 3. above
The resulting post will be 100% impersonated. Not just the name and icon as mentioned in other answers, but it'll 100% function as if it came from the user.

I hope this will help those who are still facing this issue.
First give the chat:write and chat:write.customize scope to your bot. The scope chat:write.customize Send messages as #your_slack_app with a customized username and avatar
From "OAuth & Permissions" settings get the bot OAuth token or even bot access token (both will work).
Then set the arguments like the following.
username to specify the username for the published message.
icon_url to specify a URL to an image to use as the profile photo alongside the message.
icon_emoji to specify an emoji (using colon shortcodes, eg. :white_check_mark:) to use as the profile photo alongside the message.
You can visit the docs from here

Meteor: Adding fields to Third Party User creation

I am using the user-accounts package to manage the Account System in my app.
I have also integrated Google, Github, Twitter and other 3rd party Services.
The package works fine, but now that I need a specific page for every user, and for SEO terms, I need the url to be like this:
https://domain.com/user/username
I also have the accounts-password package. And I have added a username field, and it works fine.
But if thirdparty services are used, the popup closes and the page is redirected with the user successfully created. I read about calling Accounts.onUserCreate,
and this is my code:
Accounts.onCreateUser(function(options, user) {
var email = options.profile.email;
var ist = email.indexOf("#");
var uname = email.slice(0,ist);
user.username = uname;
if(options.profile){
user.profile = options.profile;
}
return user;
});
But it gives an error : Cannot read indexOf of undefined.
How can this be achieved?
There either can be a page, to enter the username, for every new user, or this way, the email should be sliced for username creation. (Second method is preferred.)

The error message is telling you your variable email has not been set.
When using third-party login services with Meteor, the user information is not stored within the profile of the user document. Rather, you should look for the email within the services data of that user document. For example, for Facebook, you should find this within services.facebook.email.
You may also want to consider using the user argument to find this information as the documentation states: "The user argument is created on the server and contains a proposed user object with all the automatically generated fields".

Node/Express Email + Token Authentication

I'm wondering if any Node/Express gurus could give me a little advice on if the following scenario that I'm trying to achieve is possible. I think it is, I'm just a little unsure on the best-practise way to tackle the problem.
I'm currently in the process of building a small client that will be protected. To gain access to the following the following steps must occur:
Input name + email address in a form that then sends this data in an email to an admin.
The email will containing a prebuilt link containing query params of the data that was input into the field. The link will have an API URL prior to the query params.
When the link is clicked an API request will be performed that takes the query params (mainly the email address) and grants this email address access to the client for a specific period of time such as 2 hours.
The client will go to subdomain.domain.com, enter their email address (which gets validated to check that an admin has approved the email address) and have access to the client for 2 hours. There will also be a timer with the remainding session length.
The majority of this I can take care of but I thought I'd give you an insight in to the full picture of what it is I'm trying to achieve. The part that I have queries about is section 3 and giving an email address access to the client for a specific period of time. I don't want any passwords to be involved so what is the most-secure, more-advisable solution to this? Would I have to use tokens?
I will be building the server-side using Express unless I strictly have to use Node for whatever reason.
Thanks in advance!

When the admin approves the request, the api inserts a row into a db (mongo would be easy) which expires in 2 hours (or however long). Next, when the user goes to the subdomain, they enter their email address. Your express app checks if the email is in mongo. If it is, they have access. You can stick their email in a cookie and check it that way on future requests.

Validate Facebook JavaScript API response

Is there a way to validate the response from say:
FB.api(
{
method: 'fql.query',
query: 'SELECT name, pic FROM profile WHERE id= ' + FB.getSession().uid
},
function(response) {
//...
}
);
Validating the cookie for login is easy enough using a MD5 hash and the application secret key compared to the provided sig parameter. However in the case of the api calls, what would stop someone from using firebug to change the response? Obviously this can be done on the back end for sensitive information but i'd like to keep as much of the back and forth bandwidth to Facebook on the clients end as possible.
Any thoughts?

I can't think of anything harmful the user can do other than breaking his own experience in your application UNLESS you are getting these inputs (responses) and processing them/saving them to the DB for example:
Having an input field where the user can update his FB status through it, and you want to save that to your own DB too?
In this case you would/SHOULD do the usual input validations (mysql_real_escape ..etc) anyway.
Saving the user Email?
You already can get almost all the information about the user using server-side calls once the user is authenticated and grant your application access..for instance to save the user email you shouldn't wait for the user to send it to you when you can acquire it using the email permission

Any validation you might do in JavaScript(1) would be something the user could overcome with a little JS of their own.
If you need to ensure that communications to/from Facebook are secure and not interfered with... then do it on the server.
(1) e.g.
if you had a validateFacebookResponse(resp); function... an end user simply needs to re-declare the function...
function validateFacebookResponse(resp){
return true;//always return true!
}
and any "security" you had is out the window.