I'm currently creating a CRUD api in Lumen 5.2 and want to add token authorization to it.
To make this work i found a package called tymondesigns/jwt-auth.
But after every day my users sign out.
Can i prolong this to lets say a month ?
Have you tried to use ttl feature of this package ?
It is your tokens live span.
In your config/jwt.php search for this line, and adjust the ttl accordingly.
'ttl' => 43800, // a month
Be sure to look at their wiki
https://github.com/tymondesigns/jwt-auth/wiki/Installation
All information is there.
Related
We are using Doorkeeper to handle authentication with a Ruby On Rails API. When I was looking through a database on the server, I noticed that there are a lot of records in the oauth_tokens table, a good number have expired already! To be fair, our tokens expire every 2 hours...but that still will add up for a lot of users over time.
I have looked through the documentation, and the code and am still lost
Is there a way for doorkeeper to automatically delete old, expired access tokens? (I'd prefer a set and forget sort of solution.)
I have a website in AngularJS. And a backend that is basically dumbed down to a RESTful API. Login currently works liket this:
User provides login credentials -> send to server -> Validate informations and deliver a token that will be used for future requests on the API. The API itself can be used anonymously as well.
Now I understand that in a RESTful environment, I shouldn't be using Sessions, but what if I wanted to show users that have been online in the last 15minutes? How would I determine if the user that was online within the last 15 minutes was authenticated or anonymous? I am not exactly looking for any code example but rather food for thought.
Thanks
I suggest you too add date field to user entity something like lastAccessDate and with every API request for user you update lastAccessDate to current date (now()).
To get all users that were active during last 15 minutes your just need to make query in your DB with condition: now() - lastAccessDate < 15 minutes
To track anonymous users you need to add separate entity guests, activities, shadow users, anonymous users could be good choice for that case.
Does this sound something helpful?
Edit:
Initially, the question was how to get an Office365 calendar in JSON without authentication; but, what I meant was how to get an Office365 calendar in JSON without requiring the OAuth2 step (so, for example on the server-side other authentication methods are acceptable to retrieve the calendar data).
Problem:
I would like to use the Office 365 REST API to access this published calendar (i.e. the "read" operation only since the calendar is published), so that I can "style" the calendar the way I prefer. So, I am looking for a public API approach to using one of my calendars. The code examples for the Office 365 REST API that I found use OAuth to authenticate the client. This seems like overkill.
I have come up with some possible solutions, so any suggestions on the best approach is welcome.
Background:
I have a published calendar in Office365, which gives me a feed:
http://outlook.office365.com/owa/calendar/USER#DOMAIN/CALENDAR_NAME/calendar.ics
and the URL:
http://outlook.office365.com/owa/calendar/USER#DOMAIN/CALENDAR_NAME/calendar.html
How can I do what "calendar.html" is doing, so that I can display a calendar the way I would like it to be displayed (instead of IFraming what Office365 provides)?
Example:
Here is an example URL using the REST API:
https://outlook.office365.com/api/v1.0/users/USER#DOMAIN/calendars
The browser will bring up a basic authentication dialog, so it looks like OAuth is not the only method required (one possible solution, the request could be proxied from a local server that is calling the REST API using basic authentication).
Issues:
One issue might be that the calendar "publishing" feature is meant for a limited amount of data (e.g. 1 year prior or in the future at the most) which is what I assume is what the iCalendar (*.ics) file would contain for any request.
Using the REST API with authentication assumes that there isn't a date range restriction (since one can query the calendar using the REST API, I assume you could query further back than a year).
Possible solutions:
Proxy the request from another server by making the REST API calls using basic authentication. Caching might also be needed since it appears the response times could be slow. The calendar could be either JavaScript that consumes a local endpoint, or HTML content generated at the server.
It looks like the Office365 AuthenticationContext.AcquireTokenAsync() will accept a ClientCredential (client id and secret) or also a UserCredential (simple username and password). So, I think I can run a local proxy service that uses the Office365 library by manually passing in credentials to the function that acquires a token. (I still need to test this to make sure that the function will indeed work this way.)
Simply iFrame the "calendar.html" page provide by Office 365. (Cross domain is prevented, unless it's on one of the Microsoft hosted solutions "Something Webs".)
If using the iCalendar (*.ics) feed, then one would need a transformation function for the iCalendar format to JSON (https://github.com/kewisch/ical.js), then JavaScript or a calendar library could be used to design a custom calendar. (This wouldn't be very convenient for viewing a year's worth of calendar events without cashing and providing a querying mechanism, except for displaying one month back and forward. So, some sort of ics2json to use on FullCalendar might work for only a couple months of calendar history.)
Any suggestions on the best approach (or another approach not listed here) is welcome.
The Office 365 APIs require Oauth2 in order to function. If you are using Visual Studio to develop your app, the O365 tools for Visual Studio + OWIN middleware will handle a lot of the oauth work for you.
If oauth is absolutely not an option, I'd consider using the EWS APIs instead, which can use basic authentication (more info on that here on MSDN).
I'm working with the JIRA API (without library) and I need to find out the configured time zone of the current user. I see that there is a library by JIRA that has a method getUserTimeZoneInfo. What would be the equivalent http call?
I've searched and searched in google... nothing's coming up. I'm hoping it's just my choice of search terms.
Using the JIRA REST API you can achieve this simply making the following call:
https://YourJiraServerAddress/rest/api/latest/user?username=YourUsername
You will find the loaded "timeZone" field in the response message.
and yes, don't forget to authenticate yourself...
is there a way to fetch the venues search in iOS without the user entering his password or showing some foursquare oauth website?
I don't think that this oAuth makes any sense for this kind of request, it should be just an REST api like so "https://api.foursquare.com/v2/venues/search?ll=-27.58818,-48.523248&client_id=JN00ABQBOCK5V54FQ1TWQFLOOIDU12UAZXURHXGXNK0ESJBY&client_secret=14ES1NXTCL1XC5HSLBUT4LWE4ROEDGNYKKWGGERZQGUKQ5JC"
but this one is deprecated =/
Any thoughts?
It's not deprecated, you're just missing the "versioning" parameter that specifies what version of the API you're trying to use.
Requesting https://api.foursquare.com/v2/venues/search?ll=-27.58818,-48.523248&client_id=JN00ABQBOCK5V54FQ1TWQFLOOIDU12UAZXURHXGXNK0ESJBY&client_secret=14ES1NXTCL1XC5HSLBUT4LWE4ROEDGNYKKWGGERZQGUKQ5JC&v=20111107 will remove the warning you saw in your response
Add a query string parameter to your request as follows..
&v=20111119 // Choose a proper version.
Update: this is actually a date. So make sure you send current date in yyyymmdd format against v parameter.
According to FourSquare's docs page on venue searching an acting user is no longer necessary:
Some endpoints (e.g. venue search) allow you to not act as any
particular user. We will return unpersonalized data suitable for
generic use, and the performance should be slightly better. In these
cases, pass your client ID as client_id and your client secret as
client_secret. Although the draft 11 of the OAuth2 spec provides a
mechanism for consumers to act via token entitled Client Credentials,
we do not currently support this.