Author: poush

This author has written 16 articles
Read more about the article Implementing Permissions for Orders API in Open Event API Server

Implementing Permissions for Orders API in Open Event API Server

Open Event API Server Orders API is one of the core APIs. The permissions in Orders API are robust and secure enough to ensure no leak on payment and ticketing.The permission manager provides the permissions framework to implement the permissions and proper access controls based on the dev handbook. The following table is the permissions in the developer handbook.   List View Create Update Delete Superadmin/admin ✓ ✓ ✓ ✓ ✓ Event organizer ✓ [1] ✓ [1] ✓ [1] ✓ [1][2] ✓ [1][3] Registered user ✓ [4] Everyone else Only self-owned events Can only change order status A refund will also be initiated if paid ticket Only if order placed by self Super Admins and admins are allowed to create any order with any amount but any coupon they apply is not consumed on creating order. They can update almost every field of the order and can provide any custom status to the order. Permissions are applied with the help of Permission Manager which takes care the authorization roles. For example, if a permission is set based on admin access then it is automatically set for super admin as well i.e., to the people with higher rank. Self-owned events This allows the event admins, Organizer and Co-Organizer to manage the orders of the event they own. This allows then to view all orders and create orders with or without discount coupon with any custom price and update status of orders. Event admins can provide specific status while others cannot if not has_access('is_coorganizer', event_id=data['event']): data['status'] = 'pending' And Listing requires Co-Organizer access elif not has_access('is_coorganizer', event_id=kwargs['event_id']): raise ForbiddenException({'source': ''}, "Co-Organizer Access Required") Can only change order status The organizer cannot change the order fields except the status of the order. Only Server Admin and Super Admins are allowed to update any field of the order. if not has_access('is_admin'): for element in data: if element != 'status': setattr(data, element, getattr(order, element)) And Delete access is prohibited to event admins thus only Server admins can delete orders by providing a cancelling note which will be provided to the Attendee/Buyer. def before_delete_object(self, order, view_kwargs): if not has_access('is_coorganizer', event_id=order.event.id): raise ForbiddenException({'source': ''}, 'Access Forbidden') Registered User A registered user can create order with basic details like the attendees' records and payment method with fields like country and city. They are not allowed to provide any custom status to the order they are creating. All orders will be set by default to “pending” Also, they are not allowed to update any field in their order. Any status update will be done internally thus maintaining the security of Order System. Although they are allowed to view their place orders. This is done by comparing their logged in user id with the user id of the purchaser. if not has_access('is_coorganizer_or_user_itself', event_id=order.event_id, user_id=order.user_id): return ForbiddenException({'source': ''}, 'Access Forbidden') Event Admins The event admins have one more restriction, as an event admin, you cannot provide discount coupon and even if you do it will be ignored. # Apply discount only…

Continue ReadingImplementing Permissions for Orders API in Open Event API Server
Read more about the article Generating Ticket PDFs in Open Event API Server

Generating Ticket PDFs in Open Event API Server

In the ordering system of Open Event API Server, there is a requirement to send email notifications to the attendees. These attendees receive the URL of the pdf of the generated ticket. On creating the order, first the pdfs are generated and stored in the preferred storage location and then these are sent to the users through the email. Generating PDF is a simple process, using xhtml2pdf we can generate PDFs from the html. The generated pdf is then passed to storage helpers to store it in the desired location and pdf-url is updated in the attendees record. Sample PDF PDF Template The templates are written in HTML which is then converted using the module xhtml2pdf. To store the templates a new directory was created at  app/templates where all HTML files are stored. Now, The template directory needs to be updated at flask initializing app so that template engine can pick the templates from there. So in app/__init__.py we updated flask initialization with template_dir = os.path.dirname(__file__) + "/templates" app = Flask(__name__, static_folder=static_dir, template_folder=template_dir) This allows the template engine to pick the templates files from this template directory. Generating PDFs Generating PDF is done by rendering the html template first. This html content is then parsed into the pdf file = open(dest, "wb") pisa.CreatePDF(cStringIO.StringIO(pdf_data.encode('utf-8')), file) file.close() The generated pdf is stored in the temporary location and then passed to storage helper to upload it. uploaded_file = UploadedFile(dest, filename) upload_path = UPLOAD_PATHS['pdf']['ticket_attendee'].format(identifier=get_file_name()) new_file = upload(uploaded_file, upload_path) This generated pdf path is returned here Rendering HTML and storing PDF for holder in order.ticket_holders:   if holder.id != current_user.id:       pdf = create_save_pdf(render_template('/pdf/ticket_attendee.html', order=order, holder=holder))   else:       pdf = create_save_pdf(render_template('/pdf/ticket_purchaser.html', order=order))   holder.pdf_url = pdf   save_to_db(holder) The html is rendered using flask template engine and passed to create_save_pdf and link is updated on the attendee record. Sending PDF on email These pdfs are sent as a link to the email after creating the order. Thus a ticket is sent to each attendee and a summarized order details with attendees to the purchased. send_email(   to=holder.email,   action=TICKET_PURCHASED_ATTENDEE,   subject=MAILS[TICKET_PURCHASED_ATTENDEE]['subject'].format(       event_name=order.event.name,       invoice_id=order.invoice_number   ),   html= MAILS[TICKET_PURCHASED_ATTENDEE]['message'].format(       pdf_url=holder.pdf_url,       event_name=order.event.name   ) ) References Readme - xhtml2pdf https://github.com/xhtml2pdf/xhtml2pdf/blob/master/README.rst Using xhtml2pdf and create pdfs https://micropyramid.com/blog/generating-pdf-files-in-python-using-xhtml2pdf/  

Continue ReadingGenerating Ticket PDFs in Open Event API Server
Read more about the article Copying Event in Open Event API Server

Copying Event in Open Event API Server

The Event Copy feature of Open Event API Server provides the ability to create a xerox copy of event copies with just one API call. This feature creates the complete copy of event by copying the related objects as well like tracks, sponsors, micro-locations, etc. This API is based on the simple method where an object is first removed is from current DB session and then applied make_transient. Next step is to remove the unique identifying columns like “id”, “identifier” and generating the new identifier and saving the new record. The process seems simple but becomes a little complex when you have to generate copies of media files associated and copies of related multiple objects ensuring no orders, attendees, access_codes relations are copied. Initial Step The first thing to copy the event is first to get the event object and all related objects first if view_kwargs.get('identifier').isdigit(): identifier = 'id' event = safe_query(db, Event, identifier, view_kwargs['identifier'], 'event_'+identifier) Next thing is to get all related objects to this event. Creating the new event After removing the current event object from "db.session", It is required to remove “id” attribute and regenerate “identifier” of the event. db.session.expunge(event) # expunge the object from session make_transient(event) delattr(event, 'id') event.identifier = get_new_event_identifier() db.session.add(event) db.session.commit() Updating related object with new event The new event created has new “id” and “identifier”. This new “id” is added into foreign keys columns of the related object thus providing a relationship with the new event created. for ticket in tickets: ticket_id = ticket.id db.session.expunge(ticket) # expunge the object from session make_transient(ticket) ticket.event_id = event.id delattr(ticket, 'id') db.session.add(ticket) db.session.commit() Finishing up The last step of Updating related objects is repeated for all related objects to create the copy. Thus a new event is created with all related objects copied with the single endpoint. References How to clone a sqlalchemy object https://stackoverflow.com/questions/28871406/how-to-clone-a-sqlalchemy-db-object-with-new-primary-key

Continue ReadingCopying Event in Open Event API Server
Read more about the article Reset password in Open Event API Server

Reset password in Open Event API Server

The addition of reset password API in the Open Event API Server enables the user to send a forgot password request to the server so that user can reset the password. Reset Password API is a two step process. The first endpoint allows you to request a token to reset the password and this token is sent to the user via email. The second process is making a PATCH request with the token and new password to set the new password on user’s account. Creating a Reset token This endpoint is not JSON spec based API. A reset token is simply a hash of random bits which is stored in a specific column of user’s table. hash_ = random.getrandbits(128) self.reset_password = str(hash_) Once the user completed the resetting of the password using the specific token, the old token is flushed and the new token is generated. These tokens are all one time use only. Requesting a Token A token can be requested on a specific endpoint  POST /v1/auth/reset-password The token with the direct link will be sent to registered email. link = make_frontend_url('/reset-password', {'token': user.reset_password}) send_email_with_action(user, PASSWORD_RESET, app_name=get_settings()['app_name'], link=link) Flow with frontend The flow is broken into 2 steps with front end is serving to the backend. The user when click on forget password will be redirected to reset password page in the front end which will call the API endpoint in the backend with an email to send the token. The email received will contain the link for the front end URL which when clicked will redirect the user to the front end page of providing the new password. The new password entered with the token will be sent to API server by the front end and reset password will complete. Updating Password Once clicked on the link in the email, the user will be asked to provide the new password. This password will be sent to the endpoint PATCH /v1/auth/reset-password. The body will receive the token and the new password to update. The user will be identified using the token and password is updated for the respective user. try: user = User.query.filter_by(reset_password=token).one() except NoResultFound: return abort( make_response(jsonify(error="User not found"), 404) ) else: user.password = password save_to_db(user) References Understand Self-service reset password https://en.wikipedia.org/wiki/Self-service_password_reset Python - getrandbits() https://docs.python.org/2/library/random.html

Continue ReadingReset password in Open Event API Server
Read more about the article Post Payment Charging in Open Event API Server

Post Payment Charging in Open Event API Server

Order flow in Open Event API Server follows very simple process. On successfully creating a order through API server the user receives the payment-url. API server out of the box provides support for two payment gateways, stripe and paypal. The process followed is very simple, on creating the order you will receive the payment-url. The frontend will complete the payment through that url and on completion it will hit the specific endpoint which will confirm the payment and update the order status. Getting the payment-url Payment Url will be sent on successfully creating the order. There are three type of payment-modes which can be provided to Order API on creating order. The three payment modes are “free”, “stripe” and “paypal”. To get the payment-url just send the payment mode as stripe or paypal. POST Payment After payment processing through frontend, the charges endpoint will be called so that payment verification can be done on the server end. POST /v1/orders/<identifier>/charge This endpoint receives the stripe token if the payment mode is stripe else no token is required to process payment for paypal. The response will have the order details on successful verification. Implementation The implementation of charging is based on the custom data layer in Orga Server. The custom layer overrides the Base data layer and provide the custom implementation to “create_object” method thus, not using Alchemy layer. def create_object(self, data, view_kwargs): order = Order.query.filter_by(id=view_kwargs['id']).first() if order.payment_mode == 'stripe': if data.get('stripe') is None: raise UnprocessableEntity({'source': ''}, "stripe token is missing") success, response = TicketingManager.charge_stripe_order_payment(order, data['stripe']) if not success: raise UnprocessableEntity({'source': 'stripe_token_id'}, response) elif order.payment_mode == 'paypal': success, response = TicketingManager.charge_paypal_order_payment(order) if not success: raise UnprocessableEntity({'source': ''}, response) return order With the resource class as class ChargeList(ResourceList): methods = ['POST', ] schema = ChargeSchema data_layer = { 'class': ChargesLayer, 'session': db.session } Resources Paypal Payments API https://developer.paypal.com/docs/api/payments/ Flask-json-api custom layer docs http://flask-rest-jsonapi.readthedocs.io/en/latest/data_layer.html#custom-data-layer Stripe Payments API https://stripe.com/docs/charges

Continue ReadingPost Payment Charging in Open Event API Server
Read more about the article Using Order Endpoints in Open Event API Server

Using Order Endpoints in Open Event API Server

The main feature i.e., Ordering API is added into API server. These endpoints provide the ability to work with the ordering system. This API is not simple like other as it checks for the discount codes and various other things as well. The process in layman terms is very simple, first, a user must be registered or added as an attendee into Server without any order_id associated and then the attendee details will be sent to API server as a relationship. Things needed to take care: Validating the discount code and ensure it is not exhausted Calculating the total amount on the server side by applying coupon Do not calculate amount if the user is the event admin Do not use coupon if user is event admin Handling payment modes and generating payment links Ensure that default status is always pending, unless the user is event admin Creating Order Prerequisite Before initiating the order, attendee records needs to be created associated with the event. These records will not have any order_id associated with them initially. The Order API will add the relationships. Required Body Order API requires you to send event relationship and attendee records to create order_tickets Permissions Only organizers can provide custom amount and status. Others users will get their status as pending and amount will be recalculated in server. The response will reflect the calculated amount and updated status. Also to initiate any order, user must be logged in. Guest can not create any order Payment Modes There are three payment modes, free, stripe and paypal. If payment_mode is not provided then API will consider it as “free”. Discount Codes Discount code can be sent as a relationship to the API. The Server will validate the code and will act accordingly. Validating Discount Codes Discount codes are checked to ensure they are valid, first check ensures that the user is not co-organizer # Apply discount only if the user is not event admin if data.get('discount') and not has_access('is_coorganizer', event_id=data['event']): Second, check ensures that the discount code is active if not discount_code.is_active:   raise UnprocessableEntity({'source': 'discount_code_id'}, "Inactive Discount Code") The third, Check ensures its validity is not expired if not (valid_from <= now <= valid_till):   raise UnprocessableEntity({'source': 'discount_code_id'}, "Inactive Discount Code") Fourth Check ensure that the quantity is not exhausted if not TicketingManager.match_discount_quantity(discount_code, data['ticket_holders']):   raise UnprocessableEntity({'source': 'discount_code_id'}, 'Discount Usage Exceeded') Lastly, the fifth check ensures that event id matches with given discount associated event if discount_code.event.id != data['event'] and discount_code.user_for == TICKET:   raise UnprocessableEntity({'source': 'discount_code_id'}, "Invalid Discount Code") Calculating Order Amount The next important thing is to recalculate the order amount and it will calculated only if user is not the event admin if not has_access('is_coorganizer', **view_kwargs):   TicketingManager.calculate_update_amount(order) API Response The API response apart from general fields will provide you the payment-url depending upon the payment mode you selected. Stripe : will give payment-url as stripe Paypal: will provide the payment completing url in payment-url This all explains the flow and requirements to create an order. Order API consists…

Continue ReadingUsing Order Endpoints in Open Event API Server
Read more about the article Managing Related Endpoints in Permission Manager of Open Event API Server

Managing Related Endpoints in Permission Manager of Open Event API Server

Open Event API Server has its permission manager to manage all permission to different endpoints and some of the left gaps were filled by new helper method has_access. The next challenge for permission manager was to incorporate a feature many related endpoints points to the same resource. Example: /users-events-roles/<int:users_events_role_id>/user or /event-invoices/<int:event_invoice_id>/user Both endpoints point to Users API where they are fetching the record of a single user and for this, we apply the permission “is_user_itself”. This permission ensures that the logged in user is the same user whose record is asked through the API and for this we need the “user_id” as the “id” in the permission function, “is_user_itself” Thus there is need to add the ability in permission manager to fetch this user_id from different models for different endpoints. For example, if we consider above endpoints then we need the ability to get user_id from UsersEventsRole and EventInvoice models and pass it to permission function so that it can use it for the check. Adding support To add support for multiple keys, we have to look for two things. fetch_key_url model These two are key attributes to add this feature, fetch_key_url will take the comma separated list which will be matched with view_kwargs and model receives the array of the Model Classes which will be used to fetch the related records from the model This snippet provides the main logic for this: for index, mod in enumerate(model): if is_multiple(fetch_key_url): f_url = fetch_key_url[index] else: f_url = fetch_key_url try: data = mod.query.filter(getattr(mod, fetch_key_model) == view_kwargs[f_url]).one() except NoResultFound, e: pass else: found = True if not found: return NotFoundError({'source': ''}, 'Object not found.').respond() From the above snippet we are: We iterate through the models list Check if fetch_key_url has multiple keys or not Get the key from fetch_key_url on the basis of multiple keys or single key in it. We try to attempt to get object from model for the respective iteration If there is any record/object in the database then it’s our data. Skipping further process Else continue iteration till we get the object or to the end. To use multiple mode Instead of providing the single model to the model option of permission manager, provide an array of models. Also, it is optional to provide comma separated values to fetch_key_url Now there can be scenario where you want to fetch resource from database model using different keys present on your view_kwargs for example, consider these endpoints `/notifications/<notification_id>/event` `/orders/<order_id>/event` Since they point to same resource and if you want to ensure that logged in user is organizer then you can use these two things as: fetch_key_url="notification_id, order_id" model=[Notification, Order] Permission manager will always match indexes in both options, the first key of fetch_key_url will be only used for the first key of the model and so on. Also, fetch_key_url is an optional parameter and even in multiple mode you can provide a single value as well.  But if you provide multiple commas separated values make sure you provide all values such…

Continue ReadingManaging Related Endpoints in Permission Manager of Open Event API Server
Read more about the article Custom Data Layer in Open Event API Server

Custom Data Layer in Open Event API Server

Open Event API Server uses flask-rest-jsonapi module to implement JSON API. This module provides a good logical abstraction in the data layer. The data layer is a CRUD interface between resource manager and data. It is a very flexible system to use any ORM or data storage. The default layer you get in flask-rest-jsonapi is the SQLAlchemy ORM Layer and API Server makes use of default alchemy layer almost everywhere except the case where I worked on email verification part. To add support for adding user’s email verification in API Server, there was need to create an endpoint for POST /v1/users/<int:user_id>/verify Clearly here we are working on a single resource i.e, specific user record. This requires us to use ResourceDetail and the only issue was there is no any POST method or view in ResourceDetail class. To solve this I created a custom data layer which enables me to redefine all methods and views by inheriting abstract class. A custom data layer must inherit from flask_rest_jsonapi.data_layers.base.Base. Creating Custom Layer To solve email verification process, a custom layer was created at app/api/data_layers/VerifyUserLayer.py def create_object(self, data, view_kwargs): user = safe_query(self, User, 'id', view_kwargs['user_id'], 'user_id') s = get_serializer() try: data = s.loads(data['token']) except Exception: raise UnprocessableEntity({'source': 'token'}, "Invalid Token") if user.email == data[0]: user.is_verified = True save_to_db(user) return user else: raise UnprocessableEntity({'source': 'token'}, "Invalid Token") Using custom layer in API We can easily provide custom layer in API Resource using one of the properties of the Resource Class data_layer = { 'class': VerifyUserLayer, 'session': db.session } This is all we have to provide in the custom layer, now all CRUD method will be directed to our custom data layer. Solution to our issue Setting up custom layer provides us the ability to create our custom resource methods, i.e, modifying the view for POST request and allowing us to verify the registered users in API Server. On Setting up the data layer all I need to do is create a ResourceList with using this layer and with permissions class VerifyUser(ResourceList): methods = ['POST', ] decorators = (jwt_required,) schema = VerifyUserSchema data_layer = { 'class': VerifyUserLayer, 'session': db.session } This enables me to use the custom layer, VerifyUserLayer for ResourceList resource. Resources Flask-rest-jsonapi Data layer http://flask-rest-jsonapi.readthedocs.io/en/latest/data_layer.html JSON-API Spec http://jsonapi.org/format/

Continue ReadingCustom Data Layer in Open Event API Server
Read more about the article A guide to use Permission Manager in Open Event API Server

A guide to use Permission Manager in Open Event API Server

This article provides a simple guide to use permission manager in Open Event API Server. Permission manager is constantly being improved and new features are being added into it. To ensure that all co-developers get to know about it and make use of them, this blog posts describes every part of permission manager. Bootstrapping Permission manager as a part of flask-rest-jsonapi works as a decorator for different resources of the API. There are two ways to provide the permission decorator to any view First one is to provide it in the list of decorators decorators = (api.has_permission('is_coorganizer', fetch="event_id", fetch_as="event_id", model=StripeAuthorization),) Second way is to explicitly provide it as a decorator to any view @api.has_permission('custom_arg', custom_kwargs='custom_kwargs') def get(*args, **kwargs): return 'Hello world !' In the process of booting up, we first need to understand the flow of Resources in API. All resources even before doing any schema check, call the decorators. So this way you will not get any request data in the permission methods. All you will receive is a dict of the URL parameters but again it will not include the filter parameters. Permission Manager receives five parameters as:  def permission_manager(view, view_args, view_kwargs, *args, **kwargs): First three are provided into it implicitly by flask-rest-jsonapi module view: This is the resource’s view method which is called through the API. For example, if I go to /events then the get method of ResourceList will be called. view_args: These are args associated with that view. view_kwargs: These are kwargs associated with that resource view. It includes all your URL parameters as well. args: These are the custom args which are provided when calling the permission manager. Here at permission manager is it expected that the first index of args will be the name of permission to check for. kwargs: This is the custom dict which is provided on calling the permission manager. The main pillar of the permission manager. Described below in usage. Using Permission Manager Using permission manager is basically understanding the different options you can send through the kwargs so here is the list of the things you can send to permission manager These are all described in the order of priority in permission manager method (string): You can provide a string containing the methods where permission needs to be checked as comma separated values of different methods in a string. For example: method=”GET,POST” leave_if (lambda): This receives a lambda function which should return boolean values. Based on returned value if is true then it will skip the permission check. The provided lambda function receives only parameter, “view_kwargs” Example use case can be the situation where you can leave the permission for any specifically related endpoint to some resource and would like to do a manual check in the method itself. check (lambda): Opposite to leave_if. It receives a lambda function that will return boolean values. Based on returned value, If it is true then only it will go further and check the request for permissions else will throw forbidden…

Continue ReadingA guide to use Permission Manager in Open Event API Server
Read more about the article Image Uploading in Open Event API Server

Image Uploading in Open Event API Server

Open Event API Server manages image uploading in a very simple way. There are many APIs such as “Event API” in API Server provides you data pointer in request body to send the image URL. Since you can send only URLs here if you want to upload any image you can use our Image Uploading API. Now, this uploading API provides you a temporary URL of your uploaded file. This is not the permanent storage but the good thing is that developers do not have to do anything else. Just send this temporary URL to the different APIs like the event one and rest of the work is done by APIs. API Endpoints which receives the image URLs have their simple mechanism. Create a copy of an uploaded image Create different sizes of the uploaded image Save all images to preferred storage. The Super Admin can set this storage in admin preferences To better understand this, consider this sample request object to create an event { "data": { "attributes": { "name": "New Event", "starts-at": "2002-05-30T09:30:10+05:30", "ends-at": "2022-05-30T09:30:10+05:30", "email": "example@example.com", "timezone": "Asia/Kolkata", "original-image-url": "https://cdn.pixabay.com/photo/2013/11/23/16/25/birds-216412_1280.jpg" }, "type": "event" } } I have provided one attribute as “original-image-url”, server will open the image and create different images of different sizes as "is-map-shown": false, "original-image-url": "http://example.com/media/events/3/original/eUpxSmdCMj/43c6d4d2-db2b-460b-b891-1ceeba792cab.jpg", "onsite-details": null, "organizer-name": null, "can-pay-by-stripe": false, "large-image-url": "http://example.com/media/events/3/large/WEV4YUJCeF/f819f1d2-29bf-4acc-9af5-8052b6ab65b3.jpg", "timezone": "Asia/Kolkata", "can-pay-onsite": false, "deleted-at": null, "ticket-url": null, "can-pay-by-paypal": false, "location-name": null, "is-sponsors-enabled": false, "is-sessions-speakers-enabled": false, "privacy": "public", "has-organizer-info": false, "state": "Draft", "latitude": null, "starts-at": "2002-05-30T04:00:10+00:00", "searchable-location-name": null, "is-ticketing-enabled": true, "can-pay-by-cheque": false, "description": "", "pentabarf-url": null, "xcal-url": null, "logo-url": null, "can-pay-by-bank": false, "is-tax-enabled": false, "ical-url": null, "name": "New Event", "icon-image-url": "http://example.com/media/events/3/icon/N01BcTRUN2/65f25497-a079-4515-8359-ce5212e9669f.jpg", "thumbnail-image-url": "http://example.com/media/events/3/thumbnail/U2ZpSU1IK2/4fa07a9a-ef72-45f8-993b-037b0ad6dd6e.jpg", We can clearly see that server is generating three other images on permanent storage as well as creating the copy of original-image-url into permanent storage. Since we already have our Storage class, all we need to do is to make the little bit changes in it due to the decoupling of the Open Event. Also, I had to work on these points below Fix upload module, provide support to generate url of locally uploaded file based on static_domain defined in settings Using PIL create a method to generate new image by converting first it to jpeg(lower size than png) and resize it according to the aspect ratio Create a helper method to create different sizes Store all images in preferred storage. Update APIs to incorporate this feature, drop any URLs in image pointers except original_image_url Support for generating locally uploaded file’s URL Here I worked on adding support to check if any static_domain is set by a user and used the request.url as the fallback. if get_settings()['static_domain']: return get_settings()['static_domain'] + \ file_relative_path.replace('/static', '') url = urlparse(request.url) return url.scheme + '://' + url.host + file_relative_path Using PIL create a method to create image This method is created to create the image based on any size passed it to as a parameter. The important role of this is to convert the image into jpg and then resize it on…

Continue ReadingImage Uploading in Open Event API Server