My Requirement is to sent a mail to the concerned users when a record is created. The mail contains a link to our system that lets the user interacting with the system without login. The link expires after a certain time. The mailing is done using javax.mail.
How can I expire the link?
Use Timer#schedule(int):
// Schedule the timer to run once in 1 minute.
new Timer()
{
#Override
public void run()
{
if(remove)
{
// Either remove it
anchor.removeFromParent();
}
else
{
// Or disable it
anchor.setEnabled(false);
}
}
}.schedule(60 * 1000);
I would generate a key/ID that you add to the link and also store to a database. With filters (web.xml) you can check if the URL (ID) is still valid and pass it on to the desired page.
If you provide us with more details, we can give you a more detailed answer.
Related
I need to implement a basic snmp agent into my application. This agent should be able to answer get and set requests from snmp browsers on my own OID's. Since most examples for snmp4j are quite old and use the "extend the org.snmp4j.agent.BaseAgent.classapproach" there are of little use.
Therefore tried to understand and strip down the org.snmp4j.agent.example.SampleAgentincluded inside the snmp4j-agent-3.2.1.jar. I managed to get an example working with just the mandatory MIB's ( i at least think they are required because the source of the AgentConfigManager states in a comment they are mandatory snmpv2MIB, snmpMpdMib, targetMIB, communityMIB, notificationMIB, frameworkMIB, usmMIB, vacmMIB, tlsTmMib ) provided by the sample config file.
I than added a custom OID to query to the agend using the following code
MOServer server = new DefaultMOServer();
MOServer[] moServers = new MOServer[]{server};
...
AgentConfigManager agent = new AgentConfigManager(new OctetString(MPv3.createLocalEngineID()),
messageDispatcher,
null,
moServers,
ThreadPool.create("SampleAgent", 3),
configurationFactory,
new DefaultMOPersistenceProvider(moServers, configFile),
new EngineBootsCounterFile(bootCounterFile), null, dhKickstartParameters);
...
agent.initialize();
...
server.register(new MOScalar(new OID("1.someIODshere.0"), MOAccessImpl.ACCESS_READ_ONLY, new OctetString("object 1")), null);
Now i'm missing a way to intercept get or set requests from snmp managers / browsers to return a dynamic value or change the program behavior according to the request.
I kind of expect to be able to bind a kind of event listener to this OID to get notified on requests / changes.
How to watch an OID?
I found it. I was looking at the wrong place. I thought a had to add a listener to the agent, but instead i have to add the listener to the server.
server.addLookupListener(new MOServerLookupListener() {
#Override
public void lookupEvent(MOServerLookupEvent event) {
System.out.println();
((MOScalar)event.getLookupResult()).setValue(new OctetString(new Date().toString()));
}
#Override
public void queryEvent(MOServerLookupEvent event) {
System.out.println();
}
},moScalar);
I can now react to the requests. YAY!
Changing the email address of the currently logged in user works just fine using the updateEmail method of the user object, however it appears as if that change is not replicated to other logins, which still keep the previous email address.
Is there any notification I need to subscribe to / catch in order to be notified by such a change or is there another way to accomplish that?
Me, as a long time Firebaser, I read the docs a lot, like a lot. And I do have a workaround for this since there aren’t any built in.
First, if you provide multiple sessions per user, you’d want to use the reauthenticate method.
Re-authenticate a user
Some security-sensitive actions—such as deleting an account, setting a
primary email address, and changing a password—require that the user
has recently signed in. If you perform one of these actions, and the
user signed in too long ago, the action fails with the
FIRAuthErrorCodeCredentialTooOld error. When this happens,
re-authenticate the user by getting new sign-in credentials from the
user and passing the credentials to reauthenticate. For example:
let user = Auth.auth().currentUser
var credential: AuthCredential
// Prompt the user to re-provide their sign-in credentials
user?.reauthenticate(with: credential) { error in
if let error = error {
// An error happened.
} else {
// User re-authenticated.
}
}
Using this, you’d get the error 90% percent of the time because of old credentials.
Or:
(1) On the change process. Set a specific key for the user on your real-time database or Firestore,
(2) Check for that specific key on your app, if existed. That means the user needs to be re authenticated. Firebase will update the user credential on every new login.
I hope it helps.
Here’s the docs:
Manage users on Firebase
What I want to do:
I am trying to make a simple program that posts 5-10 statuses, at a time, on a page's wall. The post to the page will have to be done under the name of the page.
I've read tons of badly written Facebook Developers documentation and I'm reaching the point of confusion where I don't even know what questions to ask. So her I am.
My code so far:
I manually got the Page Access token manually, by this method:
Go to https://developers.facebook.com/tools/explorer
At the GET request form, down there, fill in me/accounts
You'll get a Javascript representation of your basic user data. Find the page you want.
Note the access_token and id fields, we're going to use them in the code below.
Thus, after getting the page Access token manually (And the ID of the page, of course)
import com.restfb.DefaultFacebookClient;
import com.restfb.FacebookClient;
import com.restfb.Parameter;
import com.restfb.exception.FacebookException;
import com.restfb.types.FacebookType;
import com.restfb.types.Page;
import com.restfb.types.User;
/**
*
* #author dsfounis
*/
public class FacebookConnector {
/* Variables */
private final String pageAccessToken = "GOT_THIS_FROM_THE_METHOD_ABOVE";
private final String pageID = "THIS_TOO";
private FacebookClient fbClient;
private User myuser = null; //Store references to myr user and page
private Page mypage = null; //for later use. In this question's context, these
//references are useless.
private int counter = 0;
public FacebookConnector() {
try {
fbClient = new DefaultFacebookClient(pageAccessToken);
myuser = fbClient.fetchObject("me", User.class);
mypage = fbClient.fetchObject(pageID, Page.class);
counter = 0;
} catch (FacebookException ex) { //So that you can see what went wrong
ex.printStackTrace(System.err); //in case you did anything incorrectly
}
}
public void makeTestPost() {
fbClient.publish(pageID + "/feed", FacebookType.class, Parameter.with("message", Integer.toString(counter) + ": Hello, facebook World!"));
counter++;
}
}
The problem:
The code above works. The thing is, it works temporarily. The page access token that I get has an expiration time of one hour, and I need to manually go through the process of obtaining it, every time that I run the program. What is the point of automating a process if I keep some aspects of it manual?
So I have to ask you: Can I do the process above programmatically, and obtain a fresh page access token at program launch?
Can I, maybe, use a better API to do something as simple as just post a couple of things on a Page's wall, every day?
My application is a console one, and I would like to stay away from implementing needless Logins, even though if you tell me that it is needed, it's going to be a bother I'll have to go through.
As a note: I've got the application registered in Facebook Developers, albeit only as a basic app. To get more permissions, I need to show proof of Facebook Login implementation, and as I say in the title, it's something I'll have to avoid.
There is no automatic process to obtain an access token. If there was, it will defeat the whole purpose of the OAuth flow. For pet projects and tests it's okay to use the Graph API Explorer but for public applications involving users it is mandatory that the user manually selects the login dialog.
Under your current scenario you can extend the user token using the method mentioned here https://developers.facebook.com/docs/roadmap/completed-changes/offline-access-removal/
Scenario 5: Page Access Tokens
When a user grants an app the manage_pages permission, the app is able
to obtain page access tokens for pages that the user administers by
querying the [User ID]/accounts Graph API endpoint. With the migration
enabled, when using a short-lived user access token to query this
endpoint, the page access tokens obtained are short-lived as well.
Exchange the short-lived user access token for a long-lived access
token using the endpoint and steps explained earlier.
https://graph.facebook.com/oauth/access_token?
client_id=APP_ID&
client_secret=APP_SECRET&
grant_type=fb_exchange_token&
fb_exchange_token=EXISTING_ACCESS_TOKEN
By using a
long-lived user access token, querying the [User ID]/accounts endpoint
will now provide page access tokens that do not expire for pages that
a user manages. This will also apply when querying with a non-expiring
user access token obtained through the deprecated offline_access
permission.
A simple program used only by the owner of the application does not need approval from Facebook.
e.g. https://www.facebook.com/phwdbot
I am trying to create a webapplication using Spring. The webapplication is a beta/demo site, which is invitation only. So, I need to generate a link to the webapplication url, appending a unique id, which would be valid for 24 hours. User can use that link for 24 hours and make use of the (I kind of also have plans of restricting the user by ip)
To achieve such token generation and expiry, should I just rely on the container with session time out to do it? or does it make sense to create spring backed service layer with token creation and expiry services?
EDIT
Now that I have a bounty on this to draw more attention, I thought I will rephrase the question so that it makes more sense - what would be a good strategy to force users out of a web application after a certain period of time?
Relying on session timeout would not be sufficient solution .
I am not acquaint with Spring . I would put my generic solution as below for any web application having requirement as yours :
Invitation is assumed to include a link to the Web Application .
The link is assumed to include the unique id .
The Beta/Demo user table is assumed to have a beta-expiry ( datetime ) column to hold the expiry date and time .
When your web application is accessed using the link in the invitation , update the beta-expiry column for that unique_id considering 24 hrs from then .
When a Beta/Demo user attempts to sign in , check the beta-expiry column for that particular user and allow access if the expiry is not reached . Display appropriate message in case of expiry .
Whenever a signed in Beta/Demo user performs subsequent accesses to your web application , check the beta-expiry column for that particular user and allow access if the expiry is not reached . Display appropriate message in case of expiry .
If seems useful , display a countdown timer showing the left over time somewhere in the header area .
In case of extension of Beta usage for all or a portion of users , you could update the beta_expiry column appropriately .
Additionally you could also have an invitation-expiry column to hold invitation expiry considering a particular duration for eg. a 48 hrs from when the invitation was sent .
We use a little bit similar solution to sign out ( signed in ) users from our SaaS application after a particular duration of no access .
I think that you should rely more in the back-end rather than a session on a cookie, imagine the case that you set the cookie for 24 hours expiration but the client deletes the cookies from the browser, (depending on your logic) your link will generate a new session or the request will be blocked.
IMHO you can store a session cookie on the client but you need to have a second source of comparison in the server, maybe a database, no-sql document, a collection in cache, something that you can compare and check the latest access to the client.
just to put all together imagine the following use case:
the user get the invitation link and click on it
the system check if the first time they log into the system, and save that date as a "start date" and another one as "last access"
the system sets an authentication cookie with 24 hours expiration
the system track every post back/ ajax call to the server and update "last access" date
if user deletes the cookie the system check the "last access" and make a comparison with the current server date
if valid the system creates a new auth cookie with the remaining hours
if not valid the system sends a message to the user.
for the user the cookie will expire according to the time left (calculation between start date and last access)
I hope this helps.
regards
One strategy is to keep track of expiry date-time of all the users by storing the relevant data in DB and using a cache library (to reduce DB hits while checking for the expiry date). Here is a small example:
Create a DB table with columns to map user id to expiry date: id, unique_user_id, expiry_date_time. You need to create the unique user id in your code and save it in DB before sending the URL to the user with this id. You can keep null as the initial value for expiry_date_time. Create a class to represent this mapping in Java:
class UserIdWithExpiryDate{
private String userId;
private Date expiryDateTime;
...
}
Define a Service with a cacheable method that will return an instance of this for a given userId :
public interface CacheableService {
#Cacheable("expiryDates")
public UserIdWithExpiryDate getUserIdWithExpiryDate(String id);
public void updateUserIdWithExpiryDate(String userId);
}
import org.joda.time.DateTime;
#Service
public class CacheableServiceImpl implements CacheableService {
#Autowired
private YourDao dao;
#Override
public UserIdWithExpiryDate getUserIdWithExpiryDate(String id) {
return dao.getUserIdWithExpiryDate(id);
}
public void updateUserIdWithExpiryDate(String userId){
Date expiryDate = new Date(new DateTime().plusHours(24).getMillis());
dao.update(userId, expiryDate);
}
}
The result of getUserIdWithExpiryDate method is stored into the cache so on subsequent invocations (with the same argument), the value in the cache is returned without having to actually execute the method.
Next step is to check the user's expiry date while accessing the site. This can be done using OncePerRequestFilter:
#Component("timeoutFilter")
public class TimeoutFilter extends OncePerRequestFilter {
#Autowired
CacheableService cacheableService;
// Here you need to decide whether to proceed with the request or not
#Override
protected void doFilterInternal(HttpServletRequest request,
HttpServletResponse response, FilterChain filterChain)
throws ServletException, IOException {
filterChain.doFilter(request, response);
}
}
Steps that can be taken inside the doFilterInternal method to check the validity of the user:
Get the user Id from request
Execute: cacheableService.getUserIdWithExpiryDate(userId)
If step 2 returns null, there is no user present with this id. You should not proceed with the request.
If step 2 returns an instance of UserIdWithExpiryDate, check the value of "expiryDateTime"
If the value of "expiryDateTime" is null,it means user is accessing the site for the first time.Update "userExpiryDate":cacheableService.updateUserIdWithExpiryDate(userId) and proceed with the request.
If "expiryDateTime" is not null, compare this with current date_time. If expiryDateTime.isAfter(currentDateTime), proceed with the request.
For caching, you can use Spring Cache Abstraction with EHCACHE.
Tokens
For this marketing purposes we generate tokens upfront, store them in a database alongside all information like restrictions to certain user account, ip ranges (for certain mobile carriers), the date and time ranges of use and so on.
In case of one time codes we just mark it as being used in the database.
To generate those codes we use Random Numbers or encode some information and use (SHA-1 or better). Then we use bigInteger.toString(36) or a different scheme and group the first 16 letters to let it look like a license key.
If we express information with it like useraccount/name or carrier (mobile) or whatever we can even validate the token without a database.
Forcing User Out
Just check for the validity of the token the first time the user starts a session or logs in. Throughout the session you just check if the token has expired (store a value in the session if you have one, append it (encrypted) in the url or whatever or check against a database.
So on every request you just check if the user has permission to access your site otherwise you block the user with an error / info page.
You can also add a java script to each page. The script can determine whether the users permission to use your site has expired by:
Encrypt the relative time that the token is valid in a hidden div and calculate the absolute time using the users local time. Then compare the absolute expire time with the user time every now and than (lets say every 3 seconds) and you can yourself all those polling and pushing (comet, ajax, websockets) behaviour.
Once the java script program notice the token has become expired remove the content sections and replace it (or mark a hidden div as visible) with the info / error page content. This way every time the user revisits pages still stored in the browser history are destroyed also. (if this is a necessity for you).
Summary
Use random tokens and a database or encrypt information (like the day the token can be used) and SHA-1.
Check the tokens validity every time the user requests a page (store the timeframe in a session / url to save roundtrips to the database)
Provide a java script that destroys local pages in the history on revisit.
Here I can think of two use cases that I have seen.
1.) This kind of management is used in applications like online tests or email verifications, where user is provided a link with some token. This link and the token is valid for some fixed period of time and can be used only once. (Ex. online tests or password reset-emails)
2.) Another use case is to provide link with a token which are also valid for a fixed period of time, but in this case the link and the token can be used any number of time within the time period allowed (Ex. Online registration forms for test or some university enrollments).
So, definitely managing this using a session only will not be a good choice as the browsers can be cleared.
So you need to maintain the pair of the link and the token at the server (May be in a DB) with some other information like last accessed time, creation date and time, Valid upto .
To be more flexible validity time for link and the token can be set differently (eg. link can be used for a set of users, but the tokens are unique to a user).
So you can use this info on every user visit to check whether the link or token is still valid and what are their last accessed time. If it turn out to be expired then you can show the relevant error message.
What about "deleting the user's account" (depends on how you are building your logging system) after 24 hours.
Coupling this with checking user's account every time (s)he loads the page, will force him/her out at the first refreshing after the 24 hours threshold passses.
You can store the id with expiration time and when a request comes in with that id check if
it's still valid
and if you are trying to accomplish something like id is valid say 5 hrs after first request then store time when the first request is made and for each subsequent request check if it's still valid
I want to have LinkedIn authentication in my website. Their API returns the desired information, the create account function is working. However, I seem to have some problems when I try to login on the site.
It seems that I get a UserEmailAddressException when I call the LoginUtil.login method.
at com.liferay.portal.service.impl.UserLocalServiceImpl.authenticate(UserLocalServiceImpl.java:2480).
It fails at
if (authType.equals(CompanyConstants.AUTH_TYPE_EA)) {
if (!Validator.isEmailAddress(login)) {
throw new UserEmailAddressException();
}
}
Here is my code :
boolean rememberMe = true;
String authType = CompanyConstants.AUTH_TYPE_EA;
try {
LoginUtil.login(request, response,
String.valueOf(user.getUserId()), user.getPassword(), rememberMe, authType);
}
catch (UserEmailAddressException ueae) {
ueae.printStackTrace();
}
The users authenticate via email address, so I guess that should be the correct authentication type?
I have added company.security.auth.type=emailAddress in portal-ext.properties, but I get the same error as without this setting.
Because Liferay documentation is unsatisfying, I would like to know how to do a proper call to the login() function so that my user will login with its LinkedIn account.
It's hard to answer this question from the amount of code that you give.
First of all: About documentation. Judging by the use of LoginUtil, you seem to be modifying Liferay's internal code in order to implement your functionality. This is an internal API that is not guaranteed to be stable and will most likely be documented last (the API documentation has improved a lot, but it's mostly about the external, public API).
You might want to look into the implementation of ServletFilters that Liferay uses for implementing other external single sign on systems. Many customers/users have implemented these successfully (I haven't looked at the state of that documentation though, but there are several SSO implementations that you can find)
Further, it will probably help, which email address is supposed to be invalid - from your code it looks like you're calling with user.getUserId() (this is numeric), but you state that you demanded the login to be through email.
Lastly, if you have configured the login method through the UI, it is saved to the database - and that setting would win. So please check ControlPanel/Portal/Portal Settings/Authentication/"How do users authenticate?" to make sure that the setting is actually asking for the email address.